Yet another approach here is download html and Javascript inside the exe and run it locally on the client computer. This permits writing a totally client side application using html and JavaScript.

Ajax is probably a good leading indicator of where web app technology is heading. An application like Gmail has completely done away with the need for a back button, tabs and the like. As more and more developers design their apps to be SSB-friendly, the lack of the elements may cease to be a consideration. Also, there’s absolutely no reason that SSBs can’t have navigation buttons and tabs (like Fluid) where appropriate.

it’s built on Moz, so is certainly not forcing Either / Or (AIR or Prism and Gears extensions?)

it’s got sqllite persistence. it’s got cool media handling. also, you can look at ‘regular pages.’ no taskbar / dock icons per tab. tho that’s doable.

as a technical product guy, i’m a bit mystified by what he audience is asking for here.

@Caltean: I agree that HTA was the first to be directionally correct. There are many approaches to solving this problem, but I suspect the winner will allow the same code-base to be deployed simultaneous across the the desktop and web and eliminate re-work.

Air is cool, and the install process is so easy that it really breaks down the “install hurdle” many other apps face, but Adobe must still let Air apps run seamless within the window to boost adoption rates and bring back the use-anywhere advantage of web-based.

I hope to god (D)HTML isn’t the platform of the future. Using HTML to draw interfaces is itself a hack/workaround–the frigg’n standard was optimized around marking up documents!

So now M$ wants to claim paternal rights about their own abortion?

That’s what I call a lovely father…

IBM did something like that back in 99. And what about Microsoft Active Desktop from 97 ? SSB’s, as you call them, are a byproduct of component oriented software.

Sure, no Flickr integration.. but there was no Flickr. We had modems and pets.com was pure GENIOUS.

Web-to-desktop bridging makes more sense, IMHO, in self-contained widgets that require no true cross-functionality with the browser. This in fact is the motivation behind our own work on bringing web widgets and social network applications out of the browser and into the desktop. A 3rd part of this series touching on the work we’re doing in Hypercube would be great.

A tabbed browser shares the same memory space for all open tabs - leaving the possibility for a browser flaw to have your logged-in bank website on one tab exposed to Joe Schmoe’s exploit code on another.

Also, browser windows/tabs are quite limited functionally by cross-site-scripting and security configurations - for very good reason, but still rule out some otherwise innovative applications. SSB’s have the potential to run protected by themselves and also to allow the user to configure the security settings just for that domain - or otherwise choose the level of trust they want for each SSB application. The SSB just becomes a common container for applications more seemingly integrated with the operating system.

I for one am curious to see where this leads…

Right now I’m using Prism with my legacy web app that includes Flex/Java/HTML components - it makes a compelling combination IF it can be secured and locked from users messing it up and tying themselves in knots.

Many of us have deep/rich existing web apps that we want to extend with technologies like flex and web services - and that seems well suited to a technology like Prism.

Opening new links is a big issue that I guess we’re all still tinkering with. New browser windows, new Bubbles/Prisms/Fluids and new Tabs within the current SSBs are all options. Its true that none of these feel like a ‘right’ solution, so more investigation for all of us.

We see SSB API unison as an important step in the path for a true platform and something that will give consumers happiness (@mark, @todd). I’m pretty sure we’ll soon get around to discuss this. We at Bubbles are making semantic steps towards this in renaming our API namespace to ‘SSB’ rather than prefixing methods with ‘BB_’.

Playing nicely with Gears is also critical in that it will allow us all to wrap up entire Applications. Imagine what it would feel like to use a version of gmail that supports gears, within an easily accessible and supercharged SSB framework, on an airplane for example.

my gmail is in a bubble and it’s an awesome experience, can’t imagine it working otherwise.

Would love to see a live community of script writers to creame more cool “smart bubbles” or whatever they are called.

nice read

So, I could log all of my web visits on the corporate wiki to a internal server for better team awareness, while not having to manage the overhead of turning on and off sharing.

Not sure it’s the right approach, but it is intriguing. Alas, prism has no support for addons right now AFAIK.

all the best!

http://msdn2.microsoft.com/en-.....36496.aspx

Introduction to HTML Applications (HTAs)
The power to build HTML Applications (HTAs) brings Microsoft Internet Explorer to the fore as a viable Microsoft Windows development platform. HTAs are full-fledged applications. These applications are trusted and display only the menus, icons, toolbars, and title information that the Web developer creates. In short, HTAs pack all the power of Internet Explorer—its object model, performance, rendering power and protocol support—without enforcing the strict security model and user interface of the browser.

Why Use HTAs
Historically, programming languages like C++ and Microsoft Visual Basic have provided the object models and access to system resources that developers demand. With HTAs, Dynamic HTML (DHTML) with script can be added to that list. HTAs not only support everything a Web page does—namely HTML, Cascading Style Sheets (CSS), scripting languages, and behaviors—but also HTA-specific functionality. This added functionality provides control over user interface design and access to the client system. Moreover, run as trusted applications, HTAs are not subject to the same security constraints as Web pages. As with any executable file, the user is asked once, before the HTA is downloaded, whether to save or run the application; if saved to the client machine, it simply runs on demand thereafter. The end result is that an HTA runs like any executable (.exe) written in C++ or Visual Basic.

HTAs are suited to many uses, whether you are prototyping, making wizards, or building full-scale applications. Everything DHTML and script can deliver—forms, multimedia, Web applications, HTML editors, and browsers—HTAs can too… and then some. In fact, HTAs can make some tasks easier. The simplicity of generating prototypes using HTAs makes it possible for designers to script dialog boxes and alerts while the C++ or Visual Basic developers program the underlying functionality.

Maybe there’s a class of websites that, when used inside these containers, is more inline with my personal user habits. The utility just isn’t that high for me at this point.