Webtop

[michael...@gmail.com]

Can someone explain why you would want a web-desktop, inside a browser, inside another desktop?

[Ross Pokorny]

Michael

Essentially, the webtop is a desktop of web apps.

While your OS desktop allows you to manage and interact with multiple
applications that are installed and running locally on your machine, a webtop
allows you to manage multiple web apps which can be organized in a number of
different layouts and which can benefit from communications mechanisms
provided by the web top (much like desktop applications benefit from the IPC
mechanisms provided by your OS).

This leads to the question "why use web apps instead of desktop apps". There
are probably many reasons why a specific use case might warrant web apps or
desktop apps, but in general I'd say that web apps are popular due to their
transient nature - they do not have to be explicitly installed or managed at
the workstation level. In scenarios where sensitive data must be stored, web
apps are also helpful in that they can minimize the amount of data that ends
up stored on the user's hard drive. Finally, web apps are highly cross-
platform. While different browsers behave differently, the same browser on
different OSes almost always behaves the same from a web developer's
perspective.

Ross Pokorny

[michael...@gmail.com]

I understand the differences between a web/desktop app.

This just feels like JDesktop all over again. You minimize and maximize. Can anyone point me to a website that follows this pattern?

[Ross Pokorny]

I had not heard of JDesktop before, but it appears to be a framework for
building desktop applications. Is that correct? If that is the case, OWF and
OZP differ in that they leave the internal implementation of apps (both client
and server) up to the app's developer and only provide the layouts and
communication that work between the apps within the browser.

There are few, if any, publicly accessible examples of OWF or OZP being used
in production. Ozone is primarily targeted at and used by internal
deployments in enterprise-sized organizations such as government agencies. In
these environments, there are often tens or hundreds of web applications
available to the organization's userbase, and OWF and OZP help to organize and
catalog those apps and to facilitate more effective workflows via the
communication APIs.

Ross Pokorny

> > On Friday, June 10, 2016 1:09:50 PM EDT michael...@gmail.com <javascript:>

[Martin Dudel]

It is probably hard to understand the usecase if you come from commercial industry where the system you develop more or less does not integrate with other systems.

We have several disparate systems, developed by different contractors/agencies, that when fused/mashed-up together provide greater utility than using the separate systems. Each system, in theory, hosts a widget/app that can be displayed on the 'desktop'. Using a common API these apps can then communicate. For example system A and B host databases. Out of the box A and B don't share data. In the desktop the two widgets from A and B can query their respective back ends and then mash up the data in a widget from System C that can do some fused analysis, or perhaps display both of the results on a map, etc. You can thus build, and persist, custom 'applications' that target specific work flows in a web browser.

You don't simply minimize and maximize since there is the communication between the widgets/apps that actually provides the power, otherwise I could get the minimize/ maximize functionality by switching between browser tabs. Granted HTML5 does allow pages now to pots messages to each stealing some of OWFs thunder.

[Ross Pokorny]

> Granted HTML5 does allow pages now to pots messages to each stealing
> some of OWFs thunder.

It is worth noting that OWF's communication mechanisms are built on top of
HTML5 postMessage in supporting (non-IE7) browsers. OWF's mechanisms aren't
so much an alternative to postMessage as an abstraction on top of it.

Ross Pokorny

[Kris Siegel]

To be fair when we were doing government work that required the usage of OWF what they really wanted was web applications, not individual widgets but the paradigm of using OWF was established and provided them the ability to use the web top as the communication layer between applications so they typically felt like they had to create widgets.

In our projects once we standardized on the APIs it was easy to either have common backend systems to support multiple web applications (especially using service discovery which allowed zero configuration of said backend systems) or use postMessage / localStorage to interact with multiple, open web applications. This is typically how commercial applications are developed and one of the reasons iSocial has essentially disappeared from the web (the standard OWF widgets were originally, partially based on).

[Miles Fidelman]

I guess I missed Martin's comment when it first went by - and it begs a response.

Since when do commercial systems not have to integrate with other systems?  They most certainly do, at all levels.

At a basic level, just think of the integration between office automation components - email, calendaring, document management, etc.

At a higher level, any kind of operations software has to integrate all over the place - order entry systems, ERP, CRM, finance, logistics, etc., etc.

In these days of extended supply and distribution chains, the amount of integration - both across functional systems, and across organizations - is immense.

The case for integration "glue" is at least as great in the commercial world as in the government space.

Miles Fidelman

On 6/28/16 7:51 PM, Kris Siegel wrote:

<snip>

--
You received this message because you are subscribed to the Google Groups "ozoneplatform-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ozoneplatform-u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

[Wagner, Jason]

Just to pile on to the subject:

OWF strongly couples three different solutions-- component reuse via widgets, presentation via a portal-like webtop, and integration via the widget APIs.  This means that OWF doesn't work well for a use case that doesn't fit all three.  

The first two tend to be show stoppers.  Complex or data-rich applications generally don't fit into the limited space of a widget.  The webtop is horrible for complex workflows, multiple monitors, assistive technology, etc -- basically anything except dashboards with limited interaction.  

The widget API is clever and powerful, but not enough to get over the UX burdens imposed by the webtop.  Especially since the API can only be used for non-sensitive data due to a lack of security (as of 7.15, at least).  It turns out that if you can nail the in-browser integration API, the webtop and widgets are quite easy for the rare case that you actually need them.  

The point of integration is to give a the end user insights from across multiple data silos.  The cause is the same in both commercial and government situations-- only the mix of reasons changes.  In government spaces, these silos are frequently created by policy, security, and development velocity/funding.  In the commercial world, there's rapidly changing landscape of apps, software-as-a-service, and the rise of BYOD and "shadow IT" that undermine enterprise integration strategies.

Tensor Wrench believes that we can double the accuracy and speed of analysts by integrating the web applications that they already use.  I've come across folks copying and pasting between two dozen applications.  They need a solution to that manual integration that's not yet another app or a long development effort.

Jason Wagner
ja...@tensorwrench.com
@nialscorva @TensorWrench