Twitter discussion on the SDK

[Bart van den Eijnden]

https://twitter.com/DonMeltz/status/316255443771072513

Personally I'm getting a bit nervous about us not making a decision for the future. Do we feel comfortable giving workshops about the SDK, and pulling people/customers in, when we don't even know if we are gonna continue this road of development, and might never upgrade to Ext 4? 

The same thing happened to Chameleon, the insiders knew it was end-of-life, but a lot people still were starting to use it without knowing the inside information. I don't like making the same mistakes twice, although the Chameleon decision was beyond my control since it was DMSG not wanting to abandon it, I had moved on already, but did not want to ruin their business case of course.

Thoughts?

I know SwissTopo is currently also in the process of deciding on whether to continue with Ext or to move on to something else.

Best regards,

Bart

-- 
Bart van den Eijnden
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[Jeffrey Johnson]

Fwiw, talked to Scott at LMN briefly today and he said that their guys
more or less feel the same way.

> --
> --
> http://groups.google.com/a/opengeo.org/group/js
>
>
>

[Andreas Hocevar]

Forwarding this to Juan, because he is not on the js list (yet).

@Juan, you might want to subscribe, because this list is where
strategic JavaScript discussions tend to happen.

Andreas.

--
--
http://groups.google.com/a/opengeo.org/group/js





--
Andreas Hocevar
OpenGeo - http://opengeo.org/

[Juan Marin (OpenGeo)]

Andreas,

Thanks for the forward, I will certainly subscribe. I agree that we have to make a decision sooner than later, and I should meet with you soon so this can be discussed. Unfortunately the last couple of weeks investor related tasks have taken most of my time, but addressing this and other tech strategic questions that we have is high on my priority list. So I would kindly ask of you guys to think about all the alternatives (I'm sure you have already) so we can discuss them and a decision that fits with the overall strategy as a whole can be taken (as you can imagine, there are similar questions about roadmap for other technologies)

Thanks


Sent from my iPhone

[Bart van den Eijnden]

Okay let write down my own thoughts on this since I really find this an important topic to make a decision on.

If we look at the use case of traditional government portals (which get a lot of negative talk I know), I think it would still be worth-while to keep the existing technology and maybe even upgrade to Ext 4. I know a lot of people are disappointed by the upgrade path that Ext provides (breaking changes, basically start from scratch for a big part), but a lot has been invested into technologies like GeoExt and GXP. I think it would be worthwhile to at least assess how much of our time it would cost to upgrade GXP to Ext4.

Also, our customers have gone down this road together with us, and it would be extremely painful IMHO to abandon the technology altogether and not have a decent upgrade path for them.

I agree that the way forward is more bootstrap like frameworks, that are designed with mobile upfront. But it will take a while until our relatively traditional customer base will be ready for such a change. Also, in this case I'm not sure if it makes sense to start something new from scratch, or join the MapBox / CartoDB movement.

Best regards,

Bart

-- 
Bart van den Eijnden
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
--
http://groups.google.com/a/opengeo.org/group/js

[Juan Marin]

Bart,

On Mon, Apr 15, 2013 at 7:55 AM, Bart van den Eijnden <bar...@opengeo.org> wrote:

Okay let write down my own thoughts on this since I really find this an important topic to make a decision on.

Please do. Short and to the point is better. 

 

If we look at the use case of traditional government portals (which get a lot of negative talk I know), I think it would still be worth-while to keep the existing technology and maybe even upgrade to Ext 4. I know a lot of people are disappointed by the upgrade path that Ext provides (breaking changes, basically start from scratch for a big part), but a lot has been invested into technologies like GeoExt and GXP. I think it would be worthwhile to at least assess how much of our time it would cost to upgrade GXP to Ext4.

I'd like to know how much time we're talking about (GeoExt / GXP on top of Ext4). We need to have a ballpark number if only for the sake of discussion, before any commitments are made. Having an estimate on this would be great. 

 

Also, our customers have gone down this road together with us, and it would be extremely painful IMHO to abandon the technology altogether and not have a decent upgrade path for them.

Decent upgrade path is key. But also consider that technology gets deprecated and abandoned all the time. It's all about what you offer instead, it has to solve the same problems, be better, faster, prettier, easier to use, etc. 

 

I agree that the way forward is more bootstrap like frameworks, that are designed with mobile upfront. But it will take a while until our relatively traditional customer base will be ready for such a change. Also, in this case I'm not sure if it makes sense to start something new from scratch, or join the MapBox / CartoDB movement.

Can you elaborate on this? Why is our user customer base not ready to use these frameworks, what makes them hard to use in those environments? Could this be a problem of education / training?

And what do you mean by joining "the MapBox / CartoDB movement"? I don't understand this last one point, especially since we ARE starting from scratch with OpenLayers 3, have made that commitment and are not thinking about pulling back from that effort. I'm especially interested to know what you mean by "movement".

Thanks for your comments Bart, really helpful. 

--
Juan Marin

[Bart van den Eijnden]

Hey Juan,

thanks for your reply, answers inline.

Best regards,

Bart

-- 
Bart van den Eijnden
OpenGeo - http://opengeo.org
Expert service straight from the developers.

On Apr 15, 2013, at 3:22 PM, Juan Marin <jma...@opengeo.org> wrote:

Bart,

On Mon, Apr 15, 2013 at 7:55 AM, Bart van den Eijnden <bar...@opengeo.org> wrote:

Okay let write down my own thoughts on this since I really find this an important topic to make a decision on.

Please do. Short and to the point is better. 

 

If we look at the use case of traditional government portals (which get a lot of negative talk I know), I think it would still be worth-while to keep the existing technology and maybe even upgrade to Ext 4. I know a lot of people are disappointed by the upgrade path that Ext provides (breaking changes, basically start from scratch for a big part), but a lot has been invested into technologies like GeoExt and GXP. I think it would be worthwhile to at least assess how much of our time it would cost to upgrade GXP to Ext4.

I'd like to know how much time we're talking about (GeoExt / GXP on top of Ext4). We need to have a ballpark number if only for the sake of discussion, before any commitments are made. Having an estimate on this would be great. 

Given the fact that upgrading GeoExt took 1 week with about 10 developers, I am expecting the same kind of ballpark for GXP. 

But it could also be less since the widgets-style classes are easier to upgrade and GXP has quite a few of those compared to GeoExt.

 

Also, our customers have gone down this road together with us, and it would be extremely painful IMHO to abandon the technology altogether and not have a decent upgrade path for them.

Decent upgrade path is key. But also consider that technology gets deprecated and abandoned all the time. It's all about what you offer instead, it has to solve the same problems, be better, faster, prettier, easier to use, etc. 

Right, but I do wonder if future applications are still gonna having things like tree views of layers and feature grids. I'm expecting UI to change significantly given the mobile revolution.

I wouldn't call Ext deprecated technology but they've made it very hard for people to upgrade, and also given the fact that they don't have a single platform for desktop and mobile complicates things in the end.

 

I agree that the way forward is more bootstrap like frameworks, that are designed with mobile upfront. But it will take a while until our relatively traditional customer base will be ready for such a change. Also, in this case I'm not sure if it makes sense to start something new from scratch, or join the MapBox / CartoDB movement.

Can you elaborate on this? Why is our user customer base not ready to use these frameworks, what makes them hard to use in those environments? Could this be a problem of education / training?

Do you think "traditional" government GIS portals are gonna disappear in the next year? I personally don't think so.

I don't think it's a problem of education / training, IMHO it's a UI revolution but it will take time.

And what do you mean by joining "the MapBox / CartoDB movement"? I don't understand this last one point, especially since we ARE starting from scratch with OpenLayers 3, have made that commitment and are not thinking about pulling back from that effort. I'm especially interested to know what you mean by "movement".

Right, I hadn't really taken OL3 into consideration when I said this, but I'm just saying that trying to replicate around OL3 what CartoDB and MapBox have done around Leaflet doesn't make a lot of sense to me.

But your point about OL3 also points out how difficult and intertwined these decisions are.

[Juan Marin]

On Mon, Apr 15, 2013 at 9:33 AM, Bart van den Eijnden <bar...@opengeo.org> wrote:

Hey Juan,

thanks for your reply, answers inline.

Best regards,

Bart

-- 
Bart van den Eijnden
OpenGeo - http://opengeo.org
Expert service straight from the developers.

On Apr 15, 2013, at 3:22 PM, Juan Marin <jma...@opengeo.org> wrote:

Bart,

On Mon, Apr 15, 2013 at 7:55 AM, Bart van den Eijnden <bar...@opengeo.org> wrote:

Okay let write down my own thoughts on this since I really find this an important topic to make a decision on.

Please do. Short and to the point is better. 

 

If we look at the use case of traditional government portals (which get a lot of negative talk I know), I think it would still be worth-while to keep the existing technology and maybe even upgrade to Ext 4. I know a lot of people are disappointed by the upgrade path that Ext provides (breaking changes, basically start from scratch for a big part), but a lot has been invested into technologies like GeoExt and GXP. I think it would be worthwhile to at least assess how much of our time it would cost to upgrade GXP to Ext4.

I'd like to know how much time we're talking about (GeoExt / GXP on top of Ext4). We need to have a ballpark number if only for the sake of discussion, before any commitments are made. Having an estimate on this would be great. 

Given the fact that upgrading GeoExt took 1 week with about 10 developers, I am expecting the same kind of ballpark for GXP. 

But it could also be less since the widgets-style classes are easier to upgrade and GXP has quite a few of those compared to GeoExt.

Thanks. This is useful info. 

 

 

Also, our customers have gone down this road together with us, and it would be extremely painful IMHO to abandon the technology altogether and not have a decent upgrade path for them.

Decent upgrade path is key. But also consider that technology gets deprecated and abandoned all the time. It's all about what you offer instead, it has to solve the same problems, be better, faster, prettier, easier to use, etc. 

Right, but I do wonder if future applications are still gonna having things like tree views of layers and feature grids. I'm expecting UI to change significantly given the mobile revolution.

I wouldn't call Ext deprecated technology but they've made it very hard for people to upgrade, and also given the fact that they don't have a single platform for desktop and mobile complicates things in the end.

Maybe not. Mobile is going to be a big space for us, stay tuned. I believe it will influence these decisions considerably. 

 

 

I agree that the way forward is more bootstrap like frameworks, that are designed with mobile upfront. But it will take a while until our relatively traditional customer base will be ready for such a change. Also, in this case I'm not sure if it makes sense to start something new from scratch, or join the MapBox / CartoDB movement.

Can you elaborate on this? Why is our user customer base not ready to use these frameworks, what makes them hard to use in those environments? Could this be a problem of education / training?

Do you think "traditional" government GIS portals are gonna disappear in the next year? I personally don't think so.

They won't disappear immediately for sure, and I should have qualified my comments better; I think these things need to have a lifecycle, and I do believe the "desktop-like" widget approach is nearing end of life, because of the revolution that you mention. That doesn't mean that you can't offer a better story and product to a mature market, one that still thinks they need geo portals. The tricky part as you mentioned is offering them a path to something better (hence my comments about education; some of the folks asking for geo portals don't know how the web works today).

It's all about where we want to be now vs. where we want to be in the future. It's a tricky balance that needs to be found, you don't want to be too early in the adoption curve with a traditional user base, but it's also risky to wait too much, competition gets ahead of you. Ideally we do both. 

 

I don't think it's a problem of education / training, IMHO it's a UI revolution but it will take time.

And what do you mean by joining "the MapBox / CartoDB movement"? I don't understand this last one point, especially since we ARE starting from scratch with OpenLayers 3, have made that commitment and are not thinking about pulling back from that effort. I'm especially interested to know what you mean by "movement".

Right, I hadn't really taken OL3 into consideration when I said this, but I'm just saying that trying to replicate around OL3 what CartoDB and MapBox have done around Leaflet doesn't make a lot of sense to me. 

But your point about OL3 also points out how difficult and intertwined these decisions are.

Indeed. The thing I'm doing most these days is scratching my head :)

[Tim Schaub]

This is a branch in the conversation.  I'm not replying to the discussion about the future of ext/gxp/geoext related work.  Instead I'm just wanting to interject my thoughts on where we should be going with front-end tech.

When you host services that are designed for web clients, it is easier to provide documentation on how developers can use popular js frameworks to work with your services.  E.g. http://www2.developerforce.com/mobile/services/mobile-packs

I don't think the same can be said for OGC services (they aren't designed with popular web clients - browsers, phones - in mind).  Fortunately, OpenLayers can provide a bit of convenience on top of this (regardless of whether you are using WFS or a more resftul HTTP interface, you end up with features).  I think we can get very far by offering light-weight developer packs for use with OpenLayers 3.  These would be small git repos that included at a minimum examples of OL3 use with the target lib/framework (e.g. Angular, Backbone, Ember, jQuery Mobile).  They could also include a skeleton project and any adapter code.

There is a continuum between these "light-weight developer packs" and what we have with GeoExt and gxp, and I'm not trying to draw a clear line defining how far we should go.  But I do think there is good reason to start smaller and provide some choices.  If a clear favorite emerges, we can continue building functionality in that direction.

Tim

Tim Schaub
OpenGeo http://opengeo.org/

[Andreas Hocevar]

Hey Tim,

I like this idea a lot, and it is pretty much in line with my own
thoughts. Thanks for bringing it up here!

Andreas.

[Jeffrey Johnson]

Aren't these essentially template projects similar to what you would find in the PaaS world? I.e. openshift provides a whole range of template projects for all manner of frameworks and apps built on them. It's usually a 2 or 3 step process to fork and deploy. Seems like we should be aiming for something at least as easy.

> --
> --
> http://groups.google.com/a/opengeo.org/group/js
>
>
>

[Tim Schaub]

Agreed.

Here are the three steps:

    npm install -g yo grunt-cli bower generator-opengeo-angular

    yo opengeo-angular

    grunt

The one prerequisite there is node.  With that you get a few tools installed globally, you create a new project scaffolding, and you build it.  It becomes a 2 step process after you do that once.

Tim

[Jeffrey Johnson]

The really killer bit will be when you can add 2 more steps for git remote add deploy <PaaS url>;; git push deploy master

--
--
http://groups.google.com/a/opengeo.org/group/js
 
 
 

[Juan Marin]

And to add to that, the super killer feature will be when we have a web UI that takes care of all of that