sorted by: recent | see : popular

Content Tagged with Adobe + page

The most exciting part of Adobe MAX last week was a service that was announced by Paul Gubbay at the "Sneaks" session that shows cool tech that Adobe folk are working on. His (very early stage) service is called Meer Meer and it is genuinely useful.

You can plugin a URL and the system will render that page on a server farm (many browsers, cross OS) and show you the results. It can visually layer these results so you can see the differences. It was awesome.

I pinged Paul and had a nice conversation with him about the project:

Can you explain what Meer Meer is, and where you got the inspiration?

Meer Meer is the code name for a new hosted service that allows Web Pros to view their content on a variety of different browsers and operating systems without requiring them to install anything other than the standard Flash Player. The inspiration is easy. We spend a lot of time with our customers and cross-browser compatibility consistently comes up as the #1 issue unprompted. It’s a real pain and we wanted to help solve it.

What browsers and OSes are supported? This means I don't have to kick up VMWare to test in IE 6 now right? ;)

IE6 is covered :) We haven’t finalized the complete set yet but we’re committed to supporting the top browsers for Windows and Mac. We expect that mix to change over time as new browsers/versions gain market share.

What are the various views and features?

We’ve really focused on how users tweak/debug their CSS today and engineered the service to fit into that workflow. One of the unique features for Meer Meer is that it can work directly with your local content if you are using Dreamweaver. This is a big benefit as users can tweak CSS and hit the refresh button to get an immediate representation of the page on their target browsers. No need to save, publish to a public location and then view. In addition, we’ve focused on several views (1-up, side by side and onion skin).

Onion skin is the most interesting as it overlays two browser shots over each other and provides the user with complete control over the transparency. This view typically gets the big oohs and aahs :)

Can you talk about the high level implementation? I assume you have a server farm on the back end and you are rendering and sending back images of the rendered image?

That’s correct. In addition we’re using a Flex application as the client. This makes the application feel very snappy and respond like a desktop application without the need to install anything. The team has also done some great work to establish a local connection with Dreamweaver to work with local content. When you make a change to your code and switch back to Meer Meer it knows you’ve made a change and prompts you to refresh. You can choose to refresh from within Dreamweaver and a panel will update and show you the status of the screenshot retrieval in real time.

In Dreamweaver CS4 you showed taking an Ajax app, clicking around to change state, freezing the page and then sending it to Meer Meer. Can you talk more about the freezing feature and other things that you can do?

I’m really proud to be associated with this release of DW CS4. We’ve definitely pushed the envelope. Our new Live View leverages the WebKit rendering engine to provide users with a true browser experience directly within the product. This means that you can see and interact with dynamic content such as Ajax UI widgets. Furthermore, we’ve included the ability to see the Live Code that the browser generates as you interact with the page. Users can freeze JavaScript to get the page into different states and then use the new Code Navigator to jump directly to the CSS that effects the element they select. This is an added bonus for Meer Meer because we can place the page into different states, such as selecting the second pane of an Accordion widget, and then view the page in that state within Meer Meer. Other browser compatibility services simply can’t do this.

Any final thoughts on Meer Meer or other Web Pro services coming from Adobe?

We’re really excited about the future of desktop + services at Adobe. Meer Meer is a great example of what we can accomplish when we take a holistic view to solving a user challenge. We’re also very interested in extending the capabilities of our users by providing them with turn-key hosted solutions that allow them to grow their business. Content maintenance follows very closely on the heels of browser compatibility as a top challenge that our users face today. Our new InContext Editing service that is now in free preview on Adobe labs allows Web Pros to provide content editing capabilities directly within the browser to their end user. No programming required.

We look forward to hearing feedback from the community on these services to help guide our future direction.

This is an exciting server from Adobe, and shows that focusing on the Flash issue isn't the entire story. They have a lot to offer the Open Web if we look to the right places and we can continue to fight for more too :) If we support projects like Meer Meer we can make our voice heard.

Of course, this is just the beginning. I would love to see an API to the service which would allow any developer tools to mashup nicely with the service. You can also imagine actively analyzing the code to not only point out the diff in the image, but the issue in the code. When we get there, we will be in a very good place indeed :)

There were some other cool things from MAX that showed up in Labs:

• Alchemy: A research project that allows users to compile C and C++ code into ActionScript libraries (AVM2).
• Durango: Mashup tool for AIR

And for more in-browser tools, check out this nice roundup on
15 Helpful In-Browser Web Development Tools.

SitePen has built an interesting set of APIs to enable you to create better JavaScript applications that run in the AIR platform:

This new effort creates a new namespace, dair, making it even easier to
create rich desktop apps using the Dojo Toolkit and Adobe AIR like the
Dojo Toolbox.

The extensions offer convenience methods for your application, wrapping
many common AIR Patterns in Dojo-like constructors and providing an
entire framework from which to grow. Built-in persistent storage,
granular window control from creation to destruction, Window FX,
Audio/Video helpers, and extra console debugging facilities are just the
beginning.

This work was greatly inspired by our efforts working on the Dojo
Toolbox, and greatly improves and simplifies Ajax development on the AIR
platform for not only Dojo users, but anyone creating an Ajax
application inside AIR. And thanks again to Adobe for helping make this
possible.

The new namespace gives you:

• dair.AIR
• dair.Console
• dair.Window
• dair.Application
• dair.fx
• dair.Sound
• dair.Video
• dair.Icon
• dair.File

Ryan Stewart of Adobe joined us for episode 5 of the Open Web Podcast. We really want to be pragmatic Open Web citizens, so thought it would be good to hear from Ryan and get his point of view on what Adobe, and he, are thinking with respect to the Web as a-whole.

You can download the podcast directly (OGG format too), or subscribe to the series, including via iTunes).

We had a really fun chat, which had us discussing:

• Adobe's view of the Web
• Silverlight, and Alex's quote of the show: "Microsoft can't write JavaScript." Ah, come on, what about Scott Isaacs!
• Ctrl/Cmd-R is the "Make All" of the Web, and Flex
• ECMAScript, ActionScript, and the path forward
• Video: A huge Flash advantage. Where does the video tag fit in? John pointed us to the experimental vorbis support via haXe
• AIR: Ryan talked about how he sees AIR fitting into the landscape, and how he personally would love to see Geolocation APIs added
• Open Source: Ryan shares his insight on the experience Adobe has gotten from their Open Source projects (Tamarin, Flex, ...)

It was a real pleasure to have Ryan come into the lions den. He is very honest with what he does and doesn't know from within, and doesn't hold back on his own thoughts.

What would you like to ask Adobe?

If you've ever been curious as to what goes into building a Adobe AIR application, then read Kevin Dangoor's account of how the Dojo Toolbox was built:

Building the Dojo Toolbox allowed us to dive into Adobe® AIR™, and to create a blended toolchain of JavaScript, PHP, Python and Rhino (JavaScript on the Java Virtual Machine) for developing an amazing desktop application using open web technologies. Read about how we built the Toolbox and what we really think of AIR.

His explanation provides a nice high-level view of some of the challenges but blends in some granular details to such topics as SQLlite querying and file management.

The second challenge was moving to AIR’s security model. AIR provides two different kinds of sandboxes that code can execute in: the “application” sandbox and the “non-application” sandbox. The windows that you see in the Dojo Toolbox all execute their code in the application sandbox. By AIR’s rules, that means that they’re allowed to access any site on the internet and any files on disk. What that code isn’t allowed to do is dynamically evaluate more JavaScript code.

This is a good read for anyone looking to explore Adobe AIR further and leverage the platform in the future.

I was wary about posting on this one, as it does involve scantily clad women. If that offends you, skip now, and please accept my apologies, and I know that this probably fits better for a Friday Fun posting, but let's get to it:

Ok, so when I was on the Adobe AIR tour, some folks showed me an AIR app that The Sun, a gossip rag / newspaper in the UK was working on. Sure you can get the news from the website, and through RSS feeds, but how about a branded experience? (as Ryan Stewart would say!)

This newspaper puts aside the third page to introduce you to a "lovely lass" each day. This is part of their brand, and probably is a reason why it is the most read newspaper in the world (a little sad but true?).

Thus, they decided to try writing an article alert application with a twist... that being one of the lasses would walk onto your screen when there is news and show it to you. I had to admit, that I didn't think that Ajax would be able to do that.

The question is, do these brand experiences take off? Is this a gimmick? Do people really just liking their RSS feeds with as little disruption as possible.... or do they cling to certain brands and enjoy that extra touch. I somehow doubt that anyone would want a "Desktop Ajaxian" where Ben and I come out to give you the news ;)

One little annoyance that I saw after running it, is the dock icon coming and going as they poll the AIR app. I hope that is fixed in the next version of AIR (Mike Chambers just put out a call for requests).

If you have an interest in Adobe AIR, Mike Chambers has 100 free copies of the Adobe AIR for JavaScript Developers Pocketguide, and one of them could have your name on it.

All you have to do is email him with your name, shipping address, and phone number if you are outside of the US. The information will only be used to ship the book.

First come, first served.

UPDATE: After receiving 500 requests, Adobe has run out of copies. They tell us the books will go out next week.

Google and Adobe have been working on improving the indexing of Flash applications. In the past we could simply look at the SWF files and try to grab strings out of them, but there was zero context.

To go further Google uses the SWF Searchable work from Adobe to be more of a 'human' actor on the application.

This is what it doesn't do:

1. Googlebot does not execute some types of JavaScript. So if your web page loads a Flash file via JavaScript, Google may not be aware of that Flash file, in which case it will not be indexed.
2. We currently do not attach content from external resources that are loaded by your Flash files. If your Flash file loads an HTML file, an XML file, another SWF file, etc., Google will separately index that resource, but it will not yet be considered to be part of the content in your Flash file.
3. While we are able to index Flash in almost all of the languages found on the web, currently there are difficulties with Flash content written in bidirectional languages. Until this is fixed, we will be unable to index Hebrew language or Arabic language content from Flash files.

This is good news for all rich applications. One of the common worries when it comes to richer application development is "what do search engines see" and we sometimes see people go back to the simpler world just to make that happier. With the search engines stepping up themselves, we can go back to writing applications that make sense for our human users, and hope that the computers catch up. Of course, we always have to do so in a practical way.

With Silverlight 2 aimed square at Flash, many of us were interested to see what Flash 10 would have in store for us. We get our first glimpse with the Flash 10 prerelease, code named "Astro".

I installed the prerelease and recorded the demos so you can take a quick peak:

The biggest feature in my mind, is true 3D:

3D Effects - Easily transform and animate any display object through 3D space while retaining full interactivity. Fast, lightweight, and native 3D effects make motion that was previously reserved for expert users available to everyone. Complex effects are simple with APIs that extend what you already know.

There are other new features too. At a high level:

Custom Filters and Effects - Create your own portable filters, blend modes, and fills using Adobe Pixel Bender, the same technology used for many After Effects CS3 filters. Shaders in Flash Player are about 1KB and can be scripted and animated at runtime.

Advanced Text Layout - A new, highly flexible text layout engine, co-existing with TextField, enables innovation in creating new text controls by providing low-level access to text offering right-to-left and vertical text layout, plus support for typographic elements like ligatures.

Enhanced Drawing API - Runtime drawing is easier and more powerful with re-styleable properties, 3D APIs, and a new way of drawing sophisticated shapes without having to code them line by line.

Visual Performance Improvements – Applications and videos will run smoother and faster with expanded use of hardware acceleration.  By moving several visual processing tasks to the video card, the CPU is free to do more.

If you delve into the release notes you see features such as:

• Context Menu — Developers now have more control over what can be displayed in the context menu through the use of ActionScript APIs for common text field context menu items, supporting plain and rich text. The clipboard menu provides access to the clipboard in a safe and controlled way, and you can write handlers to paste text.
• File Reference runtime access — Bring users into the experience by letting them load files into your RIA. You can work with the content at runtime and even save it back when you are done through the browse dialog box. Files can be accessed as a byteArray or text using a convenient API in ActionScript without round-tripping to the server. You no longer have to know a server language or have access to a server to load or save files at runtime.
• Dynamic Streaming — Always show the best video possible with streams that can automatically adjust to changing network conditions. By changing bitrates, you can keep your user engaged and avoid start-and-stop video. Dynamic streaming provides the best possible experience to the video consumer based on their bandwidth environment. Video streams over RTMP from intended future releases of Flash Media Server can dynamically change bitrate as network conditions change. Quality of Service metrics, exposed via ActionScript and providing real-time network or CPU information, allow developers to take control of the video playback and adjust the streaming experience accordingly. This feature is part of Flash Player 10 but will only be available with intended future releases of Flash Media Server.
• Text Layout Components — An extensible library of ActionScript 3.0 text components, coming in future to Adobe Labs, provides advanced, easy-to-integrate layout functionality that enables typographic creative expression. Layout and style text with tables, inline images, and column flow through components that are compatible with both Flash and Flex, all while getting the benefits of the new text engine. Rich text components allow designers and developers to flow text and complex scripts, such as Arabic, Hebrew, and Thai, across multiple columns like a newspaper, around tables and inline images, from right-to-left, left-to-right, bi-directionally, or vertically. Selection, editing, and wrapping of text are handled as would be expected for the different layouts.

It is also interesting to put this into context with JavaFX, which was hyped last week at JavaOne (without a release yet). There were some nice demos, such as 3D video globes, and a few people said "Flash couldn't do that. No decent 3D or hardware acceleration." The bar keeps rising for all.

Ryan Stewart of Adobe and I got to give a joint talk this morning that covered Adobe AIR, Gears, and how you can build offline and desktop applications right now.

Obviously, Ryan gave an overview of AIR, and I did the same for Gears. We also discussed reasons to be excited about Web development, some of the ideas that are out there in the community, and how AIR and Gears can be seen as complementary.

We had some requests to put the slides online, so here they are below. I know it is hard to peruse slides without the talk over, but just think of it as a fun exercise to wonder what we said :)

If you are at Web 2.0 Expo, give me a shout on twitter.

Adobe continues to expand its support for the Linux platofrm by announcing the release of the Adobe AIR runtime for Linux. This expands the ability to deploy AIR desktop applications to the three major operating systems (Windows, OS X & Linux) while still using the standard web technologies developers have become accustomed to.

This release of AIR for Linux will be supported on the following distributions:

• RedHat Desktop Linux 4
• RedHat Enterprise Linux v5
• Novell Desktop Linux 9
• SUSE Linux Enterprise Desktop 10
• Ubuntu 6.06

and the following features are available with this release:

• Runtime/Application Install/Update and Uninstall.
• HTML Loader with JS support to render HTML within AIR applications.
• Local Database APIs
• File system support with support for user folders like Desktop/Documents etc.
• Desktop Integration with Drag and drop, clipboard support
• Windowing support with System chrome none/standard
• Basic transparency
• Menu support with context menu, menu bar, pop up menus and menu events.
• Networking
• Network change detection (Event.NETWORK_CHANGE )
• System wide idle detection (userIdle Event)
• NativeApplication APIs
• Capabilities (OS) API
• Mouse events
• Detection of running application (InvokeEvent.INVOKE)

Adobe has posted a FAQ to provide detailed information about this new product release.

Adobe Joins Linux Foundation

In addition to releasing AIR for Linux, Adobe has also joined the Linux Foundation to "collaborate on the advancement of Linux as a leading platform for rich Internet applications (RIA) and Web 2.0 technologies.

“Adobe’s decision to join the LF is a natural extension of its commitment to open standards and open source, which demonstrates its leadership and foresight in the software industry,” said Jim Zemlin, executive director at The Linux Foundation. “Adobe’s membership will contribute to our goal of increasing even more application development on Linux with a specific emphasis on Web 2.0 applications.”

“Adobe delivers key RIA technologies for Linux users, such as Adobe® Flash® Player and now Adobe AIR™, to deploy RIAs in the browser and on the desktop,” said David McAllister, director of standards and open source at Adobe. “The Linux Foundation is a valuable resource, providing a forum where we can work with the community to ensure Adobe RIA technologies are compatible across the Linux software platform.”

This announcement further solidifies Adobe's commitment to the linux community, having already released server-side products that work natively on the Linux platform.

We all have bits of reusable code that we store in some fashion. These snippets prove to be invaluable at helping to not "reinvent the wheel" so storing them in a safe and convenient place is important.

The MooTools team wants to make it easy for you to store your snippets easily through the use of their new Adobe AIR application, Snippely. Using the MooTools JavaScript library and the AIR SDK, Valerio Proietti and Tom Occhino created a desktop application that allows easy storage of both code snippets and notes about the code.

When we were thinking about what type of application to make our AIR playground, we tried to think of something that we'd want to use ourselves. Valerio and I are notorious for storing countless bits of code in all sorts of different languages all over our hard drives, and thought it would be nice if we had a central place to store and organize those bits of code. We came up with the idea of 'snippets', and an application called Snippely.

The nice thing about this is that they've designed Snippely so that you can organize snippets by groups and that a snippet entry can consist of multiple snips or notes.

Finally, those looking to get into AIR development will certainly benefit from the fact that the Moo team has released the app as an open source project under an MIT license. The code for Snippely is hosted on Google Code and is available for you to review.

At first when you hear "FooAjaxLibrary now supports AIR" you think "er, OK, AIR has WebKit so it supports them all doesn't it?". SitePen added support for AIR in Dojo and gave us detailed information about the changes.

The value of this document is that it gives hints to us Ajax folk as we develop applications running on AIR. The main message is that the security sandbox that AIR gives you has subtle side effects that you need to be aware of.

For example, note the function(){} wrapper in the AIR-specific code:

There are other small issues such as not having eval() available post-load that you can see in the changeset. If you run into something as you develop your Ajax application in AIR, you have another resource to check (as well as the Adobe resources of course).

As well as making changes to get Dojo working in AIR, SitePen also added support for some of the AIR APIs themselves, including:

AirFileStorageProvider

The AirFileStorageProvider store the data in flat files in the app-storage directory. For example, a key of “MyKey”, value of “Hello World!”, and namespace of “MyNamespace” would create the file app-storage:/__DOJO_STORAGE/MyNamespace/MyKey which contains the text “Hello World!”. This storage provider allows for large amounts of data to be stored. Not only can strings be stored, but also objects thanks to AIR's serialize/de-serialize functionality. On the downside, data is not encrypted on disk. It would be trivial however to encrypt the information using dojox.crypto before storing the data.

AirDBStorageProvider

The AirDBStorageProvider leverages AIR's embedded database. When the provider is initialized, a database file is created in the app-storage directory and the Dojo storage table is created. The table holds the namespace, key, and value. This provider is similar to the AirFileStorageProvider in which it can store large amounts, but it cannot store serialized objects because there is no way to de-serialize them due to eval() being unavailable post-onload. The database file is not encrypted, but you could encrypted the data using dojo.crypto prior to storing the data. One advantage of the AirDBStorageProvider is there is only one file written to disk whereas the AirFileStorageProvider writes a file for each key/value.

AirEncryptedLocalStorageProvider

The AirEncryptedLocalStorageProvider uses AIR's encrypted local data store functions. Data, such as passwords, will be encrypted when being stored and decrypted when being retrieved. Similar to the AirEncryptedLocalStorageProvider, objects cannot be stored because they cannot be
de-serialized with an eval(). One limitation of the AIR's encrypted local data store is it does not provide a way to enumerate keys. To solve this, the AirEncryptedLocalStorageProvider creates a registry using AIR's encrypted local data store to track the namespaces and keys.

Dojo adds it's name to the list of Ajax frameworks that are ready for AIR work. Since Dojo has a large coverage of features (especially via the dojox.* components) it can be well suited for larger desktop apps.

Paul Krill picked up on Kevin Lynch saying "It's basically a way to take other languages and make them run on top of Flash Player" as he answered a question from the audience at Engage the other night.

Expanding on the project, Ted Patrick, Adobe technical evangelist, said the technology would allow for cross-compiling existing code from C, C++, Java, Python, and Ruby to ActionScript. This would enable components written in those languages to be integrated into a larger project, Patrick said. "That code becomes perfectly portable into our application platform," he said.

For example, an alternative PDF renderer providing a lighter version of PDF could be cross-compiled, and the Flash Player could read it and display PDFs.

"Right now, everything has to be written in ActionScript or our lower level byte code languages," said Patrick.

In Flash Player, everything has to compile down to SWF byte code, Patrick said. The byte code language inside SWF is called ActionScript byte code.

Of course, this has been talked about quite some time ago. As Tamarin grows up and becomes a solid VM, we are likely to see the polyglot come to being in full force.