Monday, April 19, 2010
Google Cloud Print Announcement- Exciting Stuff!
Google has announced Google Cloud Print, check out details from Google here. This is an incredibly important step in creating the ability to print from a variety of new applications, and devices. TechCrunch covered this announcement, too. It's very notable in light of (and in contrast to) the Apple iPad introduction, which doesn't actually appear to have a hard copy strategy. For the moment at least, printing from the iPad is dependent on some relatively primitive printing apps available from third-parties. I think this technology and approach could be far-reaching, beyond the Chrome OS; Google also needs a great printing strategy to complement Google Docs. I'm hoping that this will follow in short order; my company is in the process of adopting Google Enterprise Apps, for document collaboration. Robust printing is certainly something that we get from Microsoft Operating Systems at this point. As we transition to Cloud applications, especially for office productivity and document management, there is a great opportunity to do much more. I'm also hoping that commercial print can benefit from Google Cloud Print. My investigation is just beginning.
Wednesday, March 24, 2010
Everything as a Service (EaaS)
Some very exciting stuff going on at HP, as usual. I found this recent quote (March 19, 2010), from CEO Mark Hurd, "Services now account for 38% of Hewlett-Packard's total operating profit, more than any other segment of the firm's business. The news from one of the world's biggest PC manufacturers reflects a transition seen across the industry as computing firms away from their traditional business models. CEO Mark Hurd says the firm's acquisition of major business outsourcing firm EDS and developments in other parts of its operation have wrought significant changes. Hurd went on to say, "It's very different from how it was four or five years ago where imaging and printing group was over 80% of HP's profits," Hurd told HP's annual general meeting. "So it's a big change in the company's position and segments."
This might seem somewhat obvious, with the acquisition of EDS. And it also might seem very similar to the moves of other tech titans over the years and their services approach, notably IBM and their acquisition of PWC several years ago.
But unlike other technology or services companies, HP also owns a big piece of the imaging and printing space, an ecosystem in which they have been incredibly innovative and successful. The difference between what they are doing, and competitors, is that they have, and will continue to, move very "traditionally conducted" activities in this area to the cloud. This could be very disruptive over the next couple of years.
Visit HP's page dedicated to their Everything as a Service theme, here.
"There’s been a great deal of confusion in the industry about the cloud. In simplest terms, the cloud is the next stage in the evolution of the internet. Through the cloud, everything will be delivered as a service, from computing power to business processes to personal interactions.
At HP, over the past several years, we have executed a strategy that puts us in an ideal position to capitalize on this trend. We began with Compaq to establish ourselves as the leader in hardware, as that segment steadily moves toward open systems and architectures and always connected devices. To differentiate our hardware, we expanded our software portfolio and acquired 11 software companies in 4 years, including Mercury, Opsware and Peregrine. We then acquired EDS and put a services arm with global scale and expertise at the head of our enterprise business.
In short, we have laid the groundwork to offer an integrated cloud ecosystem — or any of its parts as discrete components — to all of our customers. At the same time, we have developed cloud services adjacent to our core businesses. From digital printing to IT infrastructure itself, we have offerings as broad and varied as HP's portfolio. "
This might seem somewhat obvious, with the acquisition of EDS. And it also might seem very similar to the moves of other tech titans over the years and their services approach, notably IBM and their acquisition of PWC several years ago.
But unlike other technology or services companies, HP also owns a big piece of the imaging and printing space, an ecosystem in which they have been incredibly innovative and successful. The difference between what they are doing, and competitors, is that they have, and will continue to, move very "traditionally conducted" activities in this area to the cloud. This could be very disruptive over the next couple of years.
Visit HP's page dedicated to their Everything as a Service theme, here.
"There’s been a great deal of confusion in the industry about the cloud. In simplest terms, the cloud is the next stage in the evolution of the internet. Through the cloud, everything will be delivered as a service, from computing power to business processes to personal interactions.
At HP, over the past several years, we have executed a strategy that puts us in an ideal position to capitalize on this trend. We began with Compaq to establish ourselves as the leader in hardware, as that segment steadily moves toward open systems and architectures and always connected devices. To differentiate our hardware, we expanded our software portfolio and acquired 11 software companies in 4 years, including Mercury, Opsware and Peregrine. We then acquired EDS and put a services arm with global scale and expertise at the head of our enterprise business.
In short, we have laid the groundwork to offer an integrated cloud ecosystem — or any of its parts as discrete components — to all of our customers. At the same time, we have developed cloud services adjacent to our core businesses. From digital printing to IT infrastructure itself, we have offerings as broad and varied as HP's portfolio. "
Tuesday, October 27, 2009
New Silverlight PDF Library
Our friend Greg Salzman from Aleyant Systems has created an open source Silverlight PDF library project. SilverPDF is based on two excellent open source projects: PdfSharp and iTextSharp. Download and contribute to the project at on Codeplex, here.
Wednesday, August 12, 2009
Mimeo and SlideRocket: Printing In The Cloud
A great example of Rich Internet Printing is the collaboration between my company, Mimeo.com, and SlideRocket. In this case, our two companies had to work together to invent a way that Sliderocket presentations could be professionally printed by Mimeo. SlideRocket is part of this new generation of RIAs. It is a Web 2.0 online presentation application that allows users to produce slideshows that have some advantages over creating presentations in desktop applications like Microsoft PowerPoint. SlideRocket runs in a web browser, instead of requiring the installation of software on your computer. It features collaboration tools that let users share slides and other assets (like graphics and movies) between presentations. Because the application is Internet-based, these users can be geographically dispersed and still share nicely. This collaboration, and user-generated content sharing, is what makes SlideRocket a unique and powerful Web 2.0 application. The company recently announced that Chuck Dietrich, former VP GM at Salesforce.com, joined the company as CEO, see the TechCrunch article here.
The SlideRocket relationship with Mimeo involved the use of the MimeoConnect SOAP API technology. This is a set of Web Services that let partners submit files, define product intent, get quotes and proofs, and submit orders, recipient addresses, shipping methods and payments. This technology solves the problem of delivering content files and placing orders; primarily the communication between our two applications in the cloud (i.e., cloud to cloud).
With that connectivity in hand, we then needed to solve how SlideRocket would take their rich content (screen-based Flash presentations) and turn it into PDF files to send to Mimeo (this was a Mimeo requirement, due to our automated PDF-based production workflow). Finally, we needed to create a way to let the non-technical SlideRocket user to specify the product intent to communicate to Mimeo for manufacturing.
To solve the former problem, SlideRocket created a server-based application that “printed” the “slide deck” to a PDF file. To solve the latter problem, Mimeo created a special interface designed to reside within the SlideRocket Flash application. When the user chooses “Print” from the SlideRocket menu, they can either choose to print on their local printer, or print “high quality with finishing options” via Mimeo.
The interface we built incorporates a subset of Mimeo’s new photo-realistic document viewer. We call it MimeoProof, because it is about as close as one can get to holding a print product in their hands by viewing it as an image on the screen. The Sliderocket version lets the user see their presentation, visually depicting paper stocks, covers and binding choices. This is an important part of helping the non-technical user specify product intent, it gives them the confidence they need to proceed with the order.
Once the user places their order on the SlideRocket site, e-commerce and print-specific transactions flow: we are sent a PDF file containing the slides, and an XML transaction containing the order information (desired quantity of books, destination, shipping method, etc.) The next day, or at some point in the near future depending on the user’s choice, a beautiful bound version of the Sliderocket slides shows up on the user’s doorstep in whatever quantity they specified.
The SlideRocket relationship with Mimeo involved the use of the MimeoConnect SOAP API technology. This is a set of Web Services that let partners submit files, define product intent, get quotes and proofs, and submit orders, recipient addresses, shipping methods and payments. This technology solves the problem of delivering content files and placing orders; primarily the communication between our two applications in the cloud (i.e., cloud to cloud).
With that connectivity in hand, we then needed to solve how SlideRocket would take their rich content (screen-based Flash presentations) and turn it into PDF files to send to Mimeo (this was a Mimeo requirement, due to our automated PDF-based production workflow). Finally, we needed to create a way to let the non-technical SlideRocket user to specify the product intent to communicate to Mimeo for manufacturing.
To solve the former problem, SlideRocket created a server-based application that “printed” the “slide deck” to a PDF file. To solve the latter problem, Mimeo created a special interface designed to reside within the SlideRocket Flash application. When the user chooses “Print” from the SlideRocket menu, they can either choose to print on their local printer, or print “high quality with finishing options” via Mimeo.
The interface we built incorporates a subset of Mimeo’s new photo-realistic document viewer. We call it MimeoProof, because it is about as close as one can get to holding a print product in their hands by viewing it as an image on the screen. The Sliderocket version lets the user see their presentation, visually depicting paper stocks, covers and binding choices. This is an important part of helping the non-technical user specify product intent, it gives them the confidence they need to proceed with the order.
Once the user places their order on the SlideRocket site, e-commerce and print-specific transactions flow: we are sent a PDF file containing the slides, and an XML transaction containing the order information (desired quantity of books, destination, shipping method, etc.) The next day, or at some point in the near future depending on the user’s choice, a beautiful bound version of the Sliderocket slides shows up on the user’s doorstep in whatever quantity they specified.
Sunday, July 12, 2009
A Visit to Google Makes Us Think...
David and I recently went to a breakfast at Google’s cool offices in NYC, at Chelsea Market. Here is some good info on the Google presence in NYC.
The event focused on Google Enterprise Apps, co-sponsored by venerable NYC IT consultants BlueWolf. Kristin Shevis, Google’s Director Northeast Google Enterprise presented, along with several other Google and BlueWolf staffers. Really good turnout, looked to me like about 100 companies present. Obviously a hot topic. A couple of excellent case studies were presented, with a focus primarily on cost savings. In addition to the formal case studies, during Q and A, several members of the audience actually answered questions from other attendees, primarily about enterprise Google mail services. It didn’t appear that anyone in the room had actually deployed non-email apps on an enterprise basis (i.e., instead of Microsoft Office)… but there was great interest. The applications are still pretty basic, but for a lot of uses, they are quite adequate.
Google documents are about collaboration. As an outside observer, beyond the cost savings, this is the primary advantage in using Google Apps. Google documents can be edited by more than one person simultaneously (actually, up to 10 people, according to Google); Spreadsheets can be edited by up to 50 people simultaneously; they can also be shared with up to 200 collaborators and viewers. Presentations can be edited by 10 people simultaneously, out of a total of 200 who can be either collaborators or viewers.
Which led David and I, during our fifteen-block power walk back to Mimeo’s NYC headquarters, to discuss some of the challenges that might be faced in professionally printing Google documents, which are “dynamic” for lack of a better word. How do you print a dynamic, collaborative document? It is clear that while the Google apps are not particularly competitive with “desktop” applications right now, someday they will be, and in the foreseeable future. Formatting is pretty weak in Google Apps right now. Control of printing is even weaker, which is somewhat surprising because it does appear in other areas that Google has some sophisticated technology for handling PDF files. I hope someone is thinking about this at Google, because there clearly will be a need for professional printing in years to come, it isn’t going to be eliminated by these collaboration tools— demand will increase for many document types coming out of these apps.
Furthermore, what does the new document model look like? I ask this because Google is not the only company working hard to put document creation, collaboration and management “in the Cloud.” There is, of course, the upcoming Microsoft Office 2010, which recently got some splash in the media and apparently, according to hype, will be a focus at WPC09, Microsoft’s Worldwide Partner Conference, which begins on Monday July 13th, in New Orleans; click here for the details.
Online office suite developer Zoho announced a couple of weeks ago that they have created a seamless API integration with Microsoft SharePoint, which I haven’t had a chance to look at in depth yet.
We will be looking at all of this very closely here, and would love to hear your thoughts on these new developments.
The event focused on Google Enterprise Apps, co-sponsored by venerable NYC IT consultants BlueWolf. Kristin Shevis, Google’s Director Northeast Google Enterprise presented, along with several other Google and BlueWolf staffers. Really good turnout, looked to me like about 100 companies present. Obviously a hot topic. A couple of excellent case studies were presented, with a focus primarily on cost savings. In addition to the formal case studies, during Q and A, several members of the audience actually answered questions from other attendees, primarily about enterprise Google mail services. It didn’t appear that anyone in the room had actually deployed non-email apps on an enterprise basis (i.e., instead of Microsoft Office)… but there was great interest. The applications are still pretty basic, but for a lot of uses, they are quite adequate.
Google documents are about collaboration. As an outside observer, beyond the cost savings, this is the primary advantage in using Google Apps. Google documents can be edited by more than one person simultaneously (actually, up to 10 people, according to Google); Spreadsheets can be edited by up to 50 people simultaneously; they can also be shared with up to 200 collaborators and viewers. Presentations can be edited by 10 people simultaneously, out of a total of 200 who can be either collaborators or viewers.
Which led David and I, during our fifteen-block power walk back to Mimeo’s NYC headquarters, to discuss some of the challenges that might be faced in professionally printing Google documents, which are “dynamic” for lack of a better word. How do you print a dynamic, collaborative document? It is clear that while the Google apps are not particularly competitive with “desktop” applications right now, someday they will be, and in the foreseeable future. Formatting is pretty weak in Google Apps right now. Control of printing is even weaker, which is somewhat surprising because it does appear in other areas that Google has some sophisticated technology for handling PDF files. I hope someone is thinking about this at Google, because there clearly will be a need for professional printing in years to come, it isn’t going to be eliminated by these collaboration tools— demand will increase for many document types coming out of these apps.
Furthermore, what does the new document model look like? I ask this because Google is not the only company working hard to put document creation, collaboration and management “in the Cloud.” There is, of course, the upcoming Microsoft Office 2010, which recently got some splash in the media and apparently, according to hype, will be a focus at WPC09, Microsoft’s Worldwide Partner Conference, which begins on Monday July 13th, in New Orleans; click here for the details.
Online office suite developer Zoho announced a couple of weeks ago that they have created a seamless API integration with Microsoft SharePoint, which I haven’t had a chance to look at in depth yet.
We will be looking at all of this very closely here, and would love to hear your thoughts on these new developments.
Monday, June 15, 2009
Flash/Flex: Printing to the Cloud
When David and I were doing the research for a paper we recently wrote, I came across the Adobe online documentation for Flex printing, which can be found here.
There are several classes discussed there: FlexPrintJob, which prints one or more objects and can split large objects for printing on multiple pages and scales the output to fit the page size. PrintDataGrid is subclass of the DataGrid control with a default appearance that is customized for printing. The class includes properties and a method that provide additional sizing and printing features. PrintAdvancedDataGrid is a subclass of the AdvancedDataGrid control with a default appearance that is customized for printing. The class includes properties and a method that provide additional sizing and printing features. FlexPrintJobScaleType defines constants used in the FlexPrintJob addObject() method.
These classes give the Flash/Flex developer control over how print can be generated from within the application. As one would expect from Adobe products, the output is designed to be directed to PostScript and "non-PostScript" printers.
While there is no native way direct the resulting print stream to the cloud, David and one of Mimeo's developers, a Flash/Flex guru Brad Johnson, came up with a way to accomplish this. An efficient and powerful (as well as simplified) way to print from the Flash/Flex platform would be to enable the developer to use the same mechanism and code path to print to the cloud as they can use to print locally today (e.g., like in the above example and described in Adobe documentation). In Flex 3 (at this writing, the latest iteration of the technology), the developer simply uses an instance of a PrintJob class, to start(), then uses addObject() one or more times, and finally employs send() print output to the OS for local printing.
To address printing in the cloud, a more universal (or web service) version of the PrintJob class would be created, perhaps called UniversalPrintJob that inherits it interface and capabilities from PrintJob but that adds the capabilities necessary for formatting and redirection of the output to the PSP. This class could provide an alternate implementation of PrintJob that would directly create a PDF or some other portable format from any Flex object added to the print job through the addObject method providing a great solution to the problem of creating an appropriate printable format.
Continuing this idea there could be additional properties, methods or parameters that could provide the additional information needed when the Send method is invoked to submit the content to a RESTful webservice. By simply providing a URL, additional job information and order data formatted as XML or JSON the send method could use the internal Flex HTTPService and/or WebService classes to seamlessly send this print job to a web enabled PSP.
There are several classes discussed there: FlexPrintJob, which prints one or more objects and can split large objects for printing on multiple pages and scales the output to fit the page size. PrintDataGrid is subclass of the DataGrid control with a default appearance that is customized for printing. The class includes properties and a method that provide additional sizing and printing features. PrintAdvancedDataGrid is a subclass of the AdvancedDataGrid control with a default appearance that is customized for printing. The class includes properties and a method that provide additional sizing and printing features. FlexPrintJobScaleType defines constants used in the FlexPrintJob addObject() method.
These classes give the Flash/Flex developer control over how print can be generated from within the application. As one would expect from Adobe products, the output is designed to be directed to PostScript and "non-PostScript" printers.
While there is no native way direct the resulting print stream to the cloud, David and one of Mimeo's developers, a Flash/Flex guru Brad Johnson, came up with a way to accomplish this. An efficient and powerful (as well as simplified) way to print from the Flash/Flex platform would be to enable the developer to use the same mechanism and code path to print to the cloud as they can use to print locally today (e.g., like in the above example and described in Adobe documentation). In Flex 3 (at this writing, the latest iteration of the technology), the developer simply uses an instance of a PrintJob class, to start(), then uses addObject() one or more times, and finally employs send() print output to the OS for local printing.
To address printing in the cloud, a more universal (or web service) version of the PrintJob class would be created, perhaps called UniversalPrintJob that inherits it interface and capabilities from PrintJob but that adds the capabilities necessary for formatting and redirection of the output to the PSP. This class could provide an alternate implementation of PrintJob that would directly create a PDF or some other portable format from any Flex object added to the print job through the addObject method providing a great solution to the problem of creating an appropriate printable format.
Continuing this idea there could be additional properties, methods or parameters that could provide the additional information needed when the Send method is invoked to submit the content to a RESTful webservice. By simply providing a URL, additional job information and order data formatted as XML or JSON the send method could use the internal Flex HTTPService and/or WebService classes to seamlessly send this print job to a web enabled PSP.
Tuesday, June 2, 2009
Silverlight and Printing
Microsoft had an amazing opportunity for Silverlight to provide the most robust printing support of any RIA platform, based on XAML and XPS technologies. Unfortunately there isn’t even a native ability to robustly support local printing in Silverlight 2. They will probably address these issues eventually (and maybe sooner rather than later, but apparently not in Silverlight 3.)
To print from Silverlight to a local printer, you basically have to control HTML/CSS in browser and print via browser to local printer (good enough output, some challenges to implement.) Jonas Follesoe has provided great detail regarding Silverlight printing, here on his blog: jonas.follesoe.no
Our interest here is Printing to the Cloud (i.e., to an Internet-based print service provider like our company Mimeo.com), more than printing to a local printer-- although you have to start somewhere, and the desktop is a good place to begin! Since Silverlight basically uses XAML as its imaging model and XPS is a subset of XAML it would seem to make sense that one could create methods for converting Silverlight content to XPS, then send this data to the Cloud for processing and/or printing. XPS is not (yet) universally accepted, but then again neither is Silverlight. That said, it is just as feasible to generate PDF from Silverlight as it is from Flex.
To print from Silverlight to a local printer, you basically have to control HTML/CSS in browser and print via browser to local printer (good enough output, some challenges to implement.) Jonas Follesoe has provided great detail regarding Silverlight printing, here on his blog: jonas.follesoe.no
Our interest here is Printing to the Cloud (i.e., to an Internet-based print service provider like our company Mimeo.com), more than printing to a local printer-- although you have to start somewhere, and the desktop is a good place to begin! Since Silverlight basically uses XAML as its imaging model and XPS is a subset of XAML it would seem to make sense that one could create methods for converting Silverlight content to XPS, then send this data to the Cloud for processing and/or printing. XPS is not (yet) universally accepted, but then again neither is Silverlight. That said, it is just as feasible to generate PDF from Silverlight as it is from Flex.
Subscribe to:
Posts (Atom)
