Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Cancel
- Home
- :
- All Communities
- :
- Developers
- :
- Developers - General
- :
- Developers Ideas
- :
- PIMP My Web App
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Follow this Idea
- Printer Friendly Page
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Esri has recently begun promoting "Information Models". For example the Information Model for Local Government is described as providing "Maps and Apps", where the Apps can be developed by partners.
A big challenge faced by these Information Models is chicken vs. egg: Users aren't attracted to information models unless there are a lot of tools built for them. Developers are reluctant to develop tools for an information model unless there is a large install base.
I propose that Esri break this impasse by providing Partner Information Model Packages (PIMPs). (Have marketing come up with a better acronym). A PIMP consists of both client side and server side components. The client side components are used by a Builder application: Add-ins for the Silverlight Viewer for ArcGIS, and/or widgets for Flex Viewer for ArcGIS. The server side components are Server Object Extensions (SOEs) or GP services tailored to work specifically with the Information Model, and accessed via the Add-in.
Esri would host a mapservice and a Builder site. The mapservice would host the server side components from the PIMP, along with a reference dataset for the Information Model. The Builder site would host the Builder for Flex and the Builder for Silverlight along with the client components from the PIMP.
This allows a marketing person to show a GIS Administrator how to build a web app without installing any ArcGIS software locally, or writing any code He would log into ArcGIS.com and use either the Flex or Silverlight builder to build an application. The marketing person will carefully explain that even though it is called a Viewer, it is in fact a Builder that can build Viewers, but they aren't really Viewers since they can do a lot more than just view. Depending on the PIMPs used by the app, it is possible to build a web app that can edit.
The Builder will present a long list of Add-Ins based on the PIMPs installed at Esri. The marketing person would pick and choose add-ins that are configured by default to point to the SOE's and GP services hosted at Esri, also based on the PIMPs. After building the app, the prospective customer can test the web app and Information Model hosted at Esri. Alternatively, the web app could be downloaded and installed on the prospective customer's IIS. The Information Model will still reside at Esri, however. The server side components of the PIMP are never downloaded from Esri without the express written consent of the partner.
Keep in mind the Google Earth Builder is gaining attention. By emphasizing server side analysis Esri can differentiate its offerings. A large PIMP ecosystem would help accomplish this.
A big challenge faced by these Information Models is chicken vs. egg: Users aren't attracted to information models unless there are a lot of tools built for them. Developers are reluctant to develop tools for an information model unless there is a large install base.
I propose that Esri break this impasse by providing Partner Information Model Packages (PIMPs). (Have marketing come up with a better acronym). A PIMP consists of both client side and server side components. The client side components are used by a Builder application: Add-ins for the Silverlight Viewer for ArcGIS, and/or widgets for Flex Viewer for ArcGIS. The server side components are Server Object Extensions (SOEs) or GP services tailored to work specifically with the Information Model, and accessed via the Add-in.
Esri would host a mapservice and a Builder site. The mapservice would host the server side components from the PIMP, along with a reference dataset for the Information Model. The Builder site would host the Builder for Flex and the Builder for Silverlight along with the client components from the PIMP.
This allows a marketing person to show a GIS Administrator how to build a web app without installing any ArcGIS software locally, or writing any code He would log into ArcGIS.com and use either the Flex or Silverlight builder to build an application. The marketing person will carefully explain that even though it is called a Viewer, it is in fact a Builder that can build Viewers, but they aren't really Viewers since they can do a lot more than just view. Depending on the PIMPs used by the app, it is possible to build a web app that can edit.
The Builder will present a long list of Add-Ins based on the PIMPs installed at Esri. The marketing person would pick and choose add-ins that are configured by default to point to the SOE's and GP services hosted at Esri, also based on the PIMPs. After building the app, the prospective customer can test the web app and Information Model hosted at Esri. Alternatively, the web app could be downloaded and installed on the prospective customer's IIS. The Information Model will still reside at Esri, however. The server side components of the PIMP are never downloaded from Esri without the express written consent of the partner.
Keep in mind the Google Earth Builder is gaining attention. By emphasizing server side analysis Esri can differentiate its offerings. A large PIMP ecosystem would help accomplish this.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.