stressfree - adobe

Adobe Genesis brings fresh AIR to business portals

David — Tue, 09 Sep 2008 11:33:14 +0000

Adobe Genesis is an AIR take on the venerable enterprise dashboard, or "enterprise desktop" as it is referred to on their development blog. Development of this business platform has not taken place in secret, but it has only recently been given its first public outing at the Office 2.0 conference. Below is a 40 minute video presentation by the Product Manager Matthias Zeller on Genesis, but if you want a higher resolution view check-out this March 2008 screen-cast.

Genesis is an attempt by Adobe to position their AIR run-time as the platform for business applications. Given the eagerness of business developers to use Flex, Adobe are hoping AIR will see similar levels of adoption. However unlike Flex, which produces Flash content that any modern web browser can consume, AIR applications reside in their own, dedicated run-time. This requirement, alongside improvements in browsers, may prove too big an obstacle for Adobe to get around, but you have to give them credit for trying.

Hidden Text

Overall Genesis is a shiny looking, but still fairly standard, enterprise dashboard. The biggest problem is that the majority of the functionality demonstrated could be achieved using modern Javascript and Flash. Besides the ability to drag and drop files to and from Genesis there appears to be very little demonstrated benefit to using the AIR run-time over a standard web browser. This is unfortunate but the signs are there that if luck went Adobe's way Genesis could become huge.

Adobe "Genesis" Overview @ Office 20

Things could get interesting for Genesis if Adobe can deliver rich, Microsoft Office-like functionality as reusable AIR widgets. If they can pull this off then they stand a chance of establishing Genesis as the "Intranet 2.0" equivalent of the 1990's Access/Visual Basic combination. One really interesting piece to this puzzle is the built-in support for third-party 'templates' and 'tiles' (aka widgets). With this 'catalog' Adobe are attempting to establish a marketplace where developers can easily sell their Genesis handiwork to businesses. If this is followed through it may provide the momentum to push Genesis from a good looking toy to integral business component.

As it stands many I.T. departments will discount Genesis because its demonstrated benefits do not outweigh the cost and hassle of supporting yet another desktop run-time. Adobe and its partners will need to work hard to construct a vibrant ecosystem which justifies the AIR investment. The clock is also against them because Microsoft will no doubt be readying a Silverlight response that leverages their existing Office monopoly.

The demise of Flashpaper sends a warning to developers

David — Mon, 08 Sep 2008 03:46:08 +0000

Do not base key functionality of your software on closed, third-party libraries - you never know what the future holds.

When Adobe purchased Marcomedia the writing was on the wall for Flashpaper from the outset. Flashpaper was Macromedia's alternative to Adobe PDF for paper-based documents on the Internet. Unlike PDF which requires a dedicated reader application (e.g. Adobe Reader), Flashpaper turns print documents into easily consumable Flash animations. Not only is Flash just as (or even more) ubiquitous as PDF, it integrates better with a user's web-experience. Consequently from Adobe's perspective letting Flashpaper live on as a potentially superior competitor to PDF on the web just did not make sense. Yet whilst this axe has been dangling above Flashpaper's head for quite some time, Adobe has only recently made it official; Flashpaper is dead, long live PDF.

This long coming announcement was a kick in the guts for businesses that have built their products on top of Flashpaper or use it for internal purposes. One bright point was that Scribd took the demise of Flashpaper as an opportunity to establish a competing product called iPaper. Whilst iPaper has some very interesting features (like integrated Google Adwords), it cannot operate 'within the firewall' on documents that are too sensitive for public release. Also iPaper's hosted architecture precludes it from being embedded into third party, redistributable applications.

All of this is a shame from a web developer's standpoint because the ability to render a document (be it PDF, Word or Powerpoint) to a slick looking Flash applet is an excellent piece of functionality. Not only does it reduce system requirements down to a Flash-enabled web browser, the end result integrates better with the browser experience. This integration leads to more possibilities when it comes to viewing and previewing the document beyond PDF's very lame ability consume an entire browser window or frame (not to mention Adobe Reader's poor load times).

The really sad part about this is that it seems Adobe is going to put Flashpaper out to pasture and simply lock-up or destroy the source code. If the product did not threaten PDF so directly it would have been a great opportunity for the company to gain some open source kudos by releasing the underlying code to the Flashpaper community. No doubt if this were to occur within twelve months there would be Flashpaper implementations in Java, .Net, Ruby, PHP and Perl. Ultimately this would have been a great thing for the industry and resulted in more Flash-content creation. Instead by circling the PDF wagons Adobe has chosen to wipe out what could have been an industry changing piece of technology in favour of some short term profits.

Unfortunately for Adobe I am sure Microsoft will not hesitate to add similar functionality to a rapidly maturing Silverlight. As a result in a few years do not be too surprised to see many sites offering Silverlight-based document viewers made possible by Microsoft-blessed (and powered) back-end tools. It will be at the point when this Silverlight-centric document future starts taking hold that Adobe execs will rue the day they terminated Flashpaper, effectively handing the 'paper web' to Microsoft.

Photoshop 10's new photomerge feature

David — Sat, 09 Jun 2007 11:38:08 +0000

Yesterday my copy of Photoshop 10 arrived and I have been playing around with it a bit. Aside from the vastly improved performance thanks to native Intel support by far the coolest time saving feature I have come across so far is the automatic photomerge option.

Oriental Bay this afternoon (click to enlarge)

The image above is two separate photographs I took today with my k800i mobile phone whilst walking around Oriental Bay. They have been automatically stitched together with Photoshop in a process that took less than ten seconds. Overall the results are pretty impressive considering that zero user input required.

Adobe ready to launch Apollo rocket at Microsoft

David — Mon, 18 Dec 2006 20:02:00 +0000

For over a year and a half Adobe has been making some interesting moves that could bridge the gap between the Web and traditional desktop applications. Adobe's first move in this strategy was to purchase Macromedia, the company behind Flash and a range of Web development tools. With these technologies in stock they are now actively developing Apollo, a cross-platform desktop framework which draws together HTML, PDF and Flash to create a Web/desktop hybrid environment (refer to this technical article for details).

TechCrunch has an excellent article about Apollo and posted a podcast with Adobe's chief software architect Kevin Lynch on the subject. With Apollo Adobe will be put on a direct collision course with Microsoft in the emerging Rich-Web application arena. Alongside Vista, Microsoft are releasing their new Windows Presentation Foundation (WPF) and XML Paper Specification (XPS) technologies. WPF and XPS are Microsoft's response to the two formats that have successfully defied their monopoly on desktop file standards: HTML and PDF. WPF is part of the .Net 3.0 framework and whilst intended to replace the aging Windows graphical API a large part of it is devoted to facilitating Rich-Web applications through XAML markup (an incompatible derivative of HTML). XPS on the other hand is a direct PDF competitor and is not intended to replace any existing Windows technology rather destroy the incumbent. Usurping these entrenched standards is important to Microsoft because as history has shown controlling a standard is equivalent to holding the high ground on a battlefield; it does not automatically win you the war but it goes a long way.

An Apollo application running on Windows

What is a Rich-Web application?

Standard Web applications as we know them today do not integrate with the user's desktop and do not perform local caching (without seriously tricky hacks). These shortcomings limit what tasks Web applications can undertake, hinder the user experience when compared to their desktop-based equivalents and most importantly result in the application ceasing to exist when Internet connectivity is lost. A Rich-Web application however exists in the grey area between the Internet and your desktop. It is designed like a traditional Web application but rather than running solely on the server it is capable of integrating with the desktop (for example searching your address book) and is capable of running locally when the Internet connection goes down and can sync itself back to the server when reconnected.

Widgets and Gadgets on the OSX and Vista desktop and applications like iFolder and the iTunes Music store are conventional examples of how a Rich-Web application would perform. None of these examples are true Rich-Web applications as they follow conventional programming idioms, but they do illustrate what is possible when the grey area between Internet and desktop is utilised to the benefit of the user. Whilst no Rich-Web applications exist on our desktops just yet the platform for running them will arrive next year in the form of Adobe's Apollo and Microsoft's .Net 3.0 frameworks.

What makes Rich-Web applications important?

Rich-Web applications are important because they simultaneously reinforce the role of the desktop and exploit the potential of the Web. Whilst some have heralded the arrival of the Web as the death knell for the Microsoft dominated desktop the majority still require functionality that is beyond the capability of even the most advanced HTML/AJAX developer. For Microsoft embracing the Rich-Web is a means of protecting the vulnerable flanks of their Office and Windows cash cows. For Adobe moving on the Rich-Web front maybe their last and best chance of becoming the dominate platform, effectively pushing Microsoft into the back seat when it comes to innovation and control of the user experience.

From a user perspective Rich-Web applications are exciting because they will bring all the benefits of the Web such as connectivity and portability without loosing those creature comforts of the desktop we've grown accustomed to. As Rich-Web applications will harness the power of the native operating system they will also be able to undertake very complicated tasks such as a fully functional Office suite or even CAD application. Their Web heritage will mean they are easy to deploy whilst their roots in the desktop will enable users to seamlessly move between the online and offline worlds without any visible change.

An Apollo application running within OSX

The effect on the Architecture, Engineering and Construction industry

Adobe and AutoDesk are actively competing for the hearts and minds of AEC industry professionals as can be witnessed in the PDF vs DWF battle being raged today. What is interesting to note is that Microsoft will be actively supporting AutoDesk's DWF standard within their XPS file format and .Net framework. When I first heard this news I could not quite understand why Microsoft would even care about such a technology but in light of Apollo this move makes a lot of sense. Through their support of DWF Microsoft ensures their Rich-Web platform maintains feature parity with Adobe's.

With Microsoft throwing their support behind DWF I would not be surprised if they use their influence to get AutoDesk to produce some very interesting Rich-Web applications for the .Net platform. These will be used to demonstrate its capabilities and encourage further developers and users to adopt .Net 3.0. Whether or not Adobe reacts to this is uncertain but it would be great for the industry if they courted a competing AEC software vendor (or vendors) to utilise the Apollo platform. The power and utility of Rich-Web collaboration tools would far surpass that available today and ultimately it would be amazing but not unreasonable to suggest that even 3D modeling tools will be delivered as a Rich-Web applications (my money is on Google Sketchup to be first).

Conclusion

With Apollo the future or Web applications look very bright. Given its roots in the dominant Web technologies (HTML, PDF, Flash) it should not struggle getting developer support. Whether it can become the dominant desktop environment and wipe the floor with .Net 3.0 is another question entirely. Given Microsoft's install base there is no doubt that .Net 3.0 will be widely deployed but whether developers choose to use it over Apollo will hinge on the polish of both platforms and the ability of the respective companies to produce excellent developer tools within a highly competitive time-frame. Perhaps the telling factor in all this is where and how Google and Yahoo align themselves to these technologies. Apollo seems a natural fit for Google and an Apollo-based GMail/Google Calendar application may just tip support in Adobe's favour. However I would not put it past Google to stay neutral or even launch their own equivalent to Apollo just to make things really interesting.

Reinventing Collaboration: An Adobe Perspective

David — Fri, 15 Sep 2006 03:23:48 +0000

The September 15th edition of the AECBytes email newsletter it featured a very good article from Patrick Aragon from Adobe. Entitled Reinventing Collaboration across Internal and External Project Teams, the article focused on findings from collaboration research conducted by Harris Interactive (on behalf of Adobe). The research concentrated on how Architecture, Engineering and Construction (AEC) professionals collaborate digitally. The research was undertaken using an online survey undertaken during April of 2006.

From the perspective of my own research the most significant finding from the article is that 72% of respondents collaborated outside their office location. This is a clear indication that the concept of a consolidated ‘office space’ where all design/construction activity takes place is eroding (or perhaps never existed). As a consequence the value of centralised, firewalled project databases or physical documentation repositories is brought into question because if project information cannot be accessed when and where it is needed what immediate value does it hold to the process? Of course these repositories are required for long-term reference and legal purposes but in the interests of moving a project forward it would appear participants are limited to the project knowledge they can personally recollect or store in a mobile device (be it laptop, phone or briefcase).

The other interesting finding was the collaboration file format breakdown as it illustrated the overwhelming majority of exchanged data is by and large straightforward text, numeric and image data stored in Word, Excel and jpeg formats respectively. The other very significant format used by participants is PDF which typically contains textual data but is capable of transferring any printable information (from pixel-based image to vector-based plan) making it difficult to classify. What all these formats have in common is that they are not semantically rich or typically considered part of a greater Building Information Model. In fact from the study it would appear that only approximately 21% of participants use some form of 3-dimensional computer model as a means of collaboration whilst 2-dimensional CAD representation is slightly higher at approximately 38%. These findings highlight the following issues of relevance to my thesis:

1. Given the emergence of Writable-Web tools like blogging, image sharing and the so-called Google Office (and equivalents) what is the future for the bulk of AEC collaboration?

2. Considering the majority of AEC collaboration takes place in formats not suited for integration with the Building Information Model does this validate the need for a looser, broader concept for dealing with design project information in an intelligent manner?

The future role of the Writeable-Web in AEC collaboration

The underlying motivation behind adoption of blogging and online photo-sharing is that these tools make very simple the publishing, consumption and feedback processes. Prior to these tools sharing information over the Internet took place primarily via email. Whilst email has the capability to ‘just work’ it is not as useful for sharing complex or time-sensitive data and requires recipients to be explicitly stated when the message is created. Consequently these issues add collaboration barriers and potentially limit the target audience.

Considering the bulk of AEC collaboration takes place in formats that are already compatible with these emerging Writable-Web services it is not unrealistic to suggest that the majority of AEC collaboration could one day take place within this arena and not be limited to isolated and proprietary files spread across participants’ various storage devices. This would dramatically change the collaboration landscape as the goal would cease to be getting discrete packets of data from A to B and instead focus on the means by which this fluid information could be efficiently directed, harnessed and monitored.

It is also important to note the increasing use of online blogging and photo-sharing tools, alongside the evolution of Web-based ‘Office’ applications and comparatively neutral formats like PDF have begun to loosen the tight grip a few software vendors have over the ownership and use of people’s data. The net effect of these Writable-Web tools is that they help in reducing the once difficult task of online collaboration, allowing participants to focus more time on the conveyed message or other pressing tasks. These open and ubiquitous data formats also ensure that in the long-term project data is not lost through software version incompatibilities or change in software vendor. This is a significant factor to consider when comparing a typical building life-cycle against the average lifespan of a software product and the more general rate of I.T. change within the AEC industry.

There are several issues to overcome before this idea can become reality. The most important is digitally representing the project team structure within this Writable-Web environment. Point to point transfer of data using tools like email manually ensures agreed upon management and communication structures are maintained. For reasons of confidentiality and consistency all project data cannot be made readable by all parties, that is just an invitation for confusion and disagreement. Likewise publishing content on the Web and locking access to a specific set of recipients significantly limits the potential usefulness of the information. What is required is an access system that balances these two requirements in a way that is both receptive to project requirements and conducive to strong collaboration.

The Building Information Model and AEC Collaboration

What is evident from the Harris Interactive/Adobe research is that basic 3-dimensional or complex Building Information Models are not widely used as a source of information within collaborative AEC environments. Arguably BIM is potentially the richest source of information within a project but that depends on its ability to consume these disparate sources of information.

Conclusive statements on the use of BIM in project collaboration cannot be drawn because it is difficult from the information presented to identify time-based usage trends. An interesting followup study to the one undertaken would be to look at the use of collaboration file formats over a period of time. What may become apparent from further study is a rapid decline in 2D CAD use or a rise in 3D model adoption which would indicate an increase in BIM adoption. This may indicate that BIM is gaining acceptance within the industry and in the long-term may satisfy more collaboration needs.

However based on the results presented it would appear that the role of Building Information Model as a collaborative tool is very limited no matter what the context. BIM as a concept is attempting to consolidate the various information streams into a concise, powerful and easily navigable model. In doing so BIM aims to increase project consistency and reduce the manual information monitoring and searching loads placed on current project participants. Unfortunately if BIM is failing to meet the collaboration needs of design participants, which from this study seems to indicate an emphasis on relatively basic information sources, then its value within the AEC design process is significantly limited. As Patrick Aragon states, “collaboration is intimately linked with communication--and to success” and if BIM cannot be a meaningful participant in this process then something is required to meet the very real information management challenges it was intended to address.