Category Archives: web authoring

mobile, open source, software development, Web, web authoring

Sencha’s Michael Mullany talks about Flash developers “flailing around for an alternative” and the Big App Rewrite

I spoke to Michael Mullany, CEO of Sencha, a company which creates HTML5 frameworks and tools for desktop and mobile browsers. Ext JS is aimed at desktop browser applications, while Sencha Touch is for mobile devices, currently Apple iOS, Google Android and Blackberry 6+. Sencha’s tools include Ext Designer, a visual application builder for Ext JS, and Sencha Animator, a designer for CSS 3 animations. Sencha Touch apps can also be packaged as native apps for iOS or Android.

At its developer conference in Austin USA earlier this month, attended by around 600, the company announced Sencha.io, a cloud service for mobile web apps, as well as presenting Sencha Touch 2.0, a major update.

image

Mullany talks on his blog about “The Big App Rewrite”:

It’s a world where HTML5 powers the client apps, and they’re enriched with local APIs that execute on everything from traditional desktops to Smart TV’s. And cloud services provide the fabric that enables continuous, shared experiences across the diversity of end-devices. We think this is the platform for the web.

Sencha is perfectly in tune with the trends towards cloud, HTML5 and mobile, which is why I was keen to speak to Mullany. I asked him to contrast Ext JS and Sencha Touch with JQuery and JQuery Mobile.

JQuery is a pretty tiny library that helps with Dom abstraction and animations but that’s it. JQuery UI gives you some visual components as well but Ext-JS is the full enchilada. It’s supposed to be the web equivalent of Cocoa or the Microsoft Windows presentation foundation. It’s got an event system, a theming system, a very rich set of user interface controls, its object oriented, and it’s got a complex layout system so you can build nested layouts that have very complex event handling among different parts of the user interface. We’ve seen user interfaces that have several thousand data elements on a page.

It also has a model-view-controller architecture library on the client side so you can structure your code properly for large applications, it’s got a theming system so you can variable-ise your colours, shapes and look and feel very easily. It also has a full data package so you can do very rich data manipulation on the client, bind data in various complex ways across variables, it’s very different than J query.

And just like you’d probably never use Ext-JS on a public web page, you’d never use JQuery to build something like Marketo or Salesforce VisualForce or a Documentum content management system, all of which use Ext-JS. Ext-JS is one of the most popular behind the firewall development libraries for desktop development.

Now on the mobile side the difference is slightly less. JQuery mobile does give you a set of user interface widgets, but the difference is also similar to the desktop … Sencha Touch is designed to let you do anything you could do with Cocoa Touch or an Android SDK or a Windows Mobile SDK. Its intent is to equip you to develop native quality experiences with native style interaction, things like fixed user interface chrome, multiple independent scrollable areas, nested layouts, those kinds of capabilities.

Our performance tends to be better cross-platform, we’ve done more performance work, we have our theming system, we have an MVC library, we have a templating system. With JQuery mobile you tend to want to add multiple things together and you can certainly assemble a collection of things that will look like Sencha Touch, but Sencha Touch is designed to be integrated, everything is designed to work the same, and the general feedback is that even though Sencha Touch is a much richer system that takes some insight to learn, you get better applications out of it.

I also asked about the new cloud service, Sencha.io. A notable feature is that according to Mullany developers do not have to touch the code that runs on the cloud, they just call its API from the client:

We call it the first client-centric HTML5 cloud, which is a set of authentication, data, data synchronisation, and geo-location services that help people build mobile applications without needing to write server side code. So you literally write your client side application in HTML 5 using Sencha SDKs and then you store your user’s data and you store your user’s authentication credentials in our cloud. You don’t have to worry about mucking around with anything from Ruby on Rails to PHP to Java, it’s all abstracted behind these very clean APIs. We think that’s the future of mobile development, that you’ll have these very thin abstracted server-side services, and and these very rich mobile clients that have off-line state and local data storage powered by HTML5. We think that model is the future of mobile web development and we obviously hope that Sencha.io will be the most popular back-end.

Sencha’s frameworks are open source and dual-licenced. You can use both Touch and Ext JS freely under the terms of the GPL v3. There is also free commercial licencing for Sencha Touch, while commercial licences for Ext JS are paid for. Sencha also has commercial tools, and I asked Mullany to describe the tool products:

We really see the three legs of the business being cloud, tools, and SDKs. We just did a preview of the Sencha Designer 2.0 release at our conference. That has support for Sencha Touch in it so you can drag and drop Sencha touch applications together and then actually package them from within the tool. The intent is also to allow you to hook up to cloud APIs from within the tool as well so it is an integrated, easy-to-use visual application builder for both desktop and touch. So that’s targeted at developers.

Sencha Animator is a little bit different. There’s no JavaScript in it really at all. It is a pure CSS 3 animation tool, and it is a traditional visual timeline with keyframe manipulation, and a style visual editor for creating rich animations.

The market we’re targeting for that is people doing interactive brand advertising on mobile. That’s where you have ubiquitous support for CSS 3 animations that are hardware accelerated so they tend to be the best performance. It’s also very web content friendly so you don’t have to write your application in Sencha Touch just to use Animator, it’s pure CSS output that you drop into whatever piece of content that you want to build.

The reason we built it is because we saw people flailing around for an alternative to doing Flash ads on mobile. Because Flash was banned from iOS, it meant that a whole segment of rich advertising that was based on Flash for the desktop had nowhere to go. They weren’t going to build native iOS applications, it had to be web. So the question then was what do you build it in, do you use JavaScript animation, do you use SVG, do you use Canvas, do you use some of the other graphic technologies such as Web GL? The answer is that CSS 3 is really the highest performance and cognitively pretty easy to wrap your head around.

People “flailing around for an alternative to doing Flash ads?” Mullany has his own agenda, but his comments do highlight the problems caused for Adobe by the success of Flash-free iPhone and iPad. I cannot help thinking that Sencha would be an attractive acquisition for Adobe or certain other companies, but I am sure smarter people than myself have thought of that.

Post sponsored by Monster for the best in IT jobs.

apple, development, internet, microsoft, professional, Web, web authoring, windows

HTML5 scorecard: Amazon Kindle Fire weak, iOS 5 great, IE10 preview one of the best

4 Comments

The Sencha blog has a great series of posts on HTML5 support on various devices. This is of direct interest to Sencha because its products are JavaScript and CSS application frameworks, Sencha Touch for mobile and ExtJS for any browser. The latest post is on the Amazon Kindle Fire – and it is weak:

The Amazon Kindle Fire doesn’t seem designed to run HTML5 apps as a primary goal. It does a good job of displaying ordinary web pages and its resolution and rendering capabilities meet that need well. But there are too many sharp edges, performance issues, and missing HTML5 features for us to recommend that any developer create web apps primarily for the Kindle Fire. The iPad 2 running iOS 5 continues to be the tablet to beat, with the PlayBook a respectable runner-up in HTML5 capabilities.

Part of the problem is that the Fire runs Android 2.3.4 (Gingerbread) which has a weaker browser than later versions. That is not the only source of disappointment though. According to Sencha’s Michael Mullany, the GPU is not used for hardware acceleration of browser content, the JavaScript timer is laggy, there is no embedded HTML5 video (videos launch in a separate player), and CSS corners are not properly anti-aliased.

But what about the Kindle’s cloud-accelerated browsing that we heard so much about when it was announced? This is the biggest disappointment:

One of the main selling points of the Kindle browser is supposed to be its cloud-caching and pipelined HTTP connection that uses the SPDY protocol. This does seem to speed up normal page browsing a little, but it’s not very noticeable and we didn’t test this rigorously. But for HTML5 web apps, where code is downloaded and executed, there doesn’t seem to be any performance difference when we tested with acceleration on and off. It doesn’t appear as if client JavaScript is executed on the server-side at all, so the Kindle does not seem to have Opera Mini-style server-side execution. And SunSpider scores were essentially the same when accelerated browsing was turned on or off.

Moving on from Kindle, it is interesting but not surprising to see a great report for HTML5 in Apple’s iOS 5. Less expected though is a big thumbs-up for HTML5 in Microsoft’s IE10 preview on Windows 8:

Simply put, (and with the caveat that we were running on the notably overpowered developer preview hardware) the IE10 HTML5 experience is one of the best we’ve seen on any platform to date. After a decade of web neglect, Microsoft is back with a vengeance.

image

The main caveat is the absence of WebGL. Microsoft is supporting its own 3D graphics library.

Another worry for Microsoft is simply the level of hostility towards the company and IE in particular, among the developer and designer community it so much wants to reach. You can get a flavour of this from some of the comments to Mullany’s post, for example:

I never really like Windows and I absolutely despise Internet Explorer. There are so many exceptions in code to be made for Internet Explorer that i stopped trying so hard to make it look the same as other browsers. Hopefully, IE 10 will stop all of these exceptions and weird additions that are made to websites that make everything instantly awful so I can actually go back to trying to make things look nice in IE. It’s really sad though that so many people use Windows and IE that we cannot ditch it for a better system and better browser.

What about Android? The most recent offering covered in the Sencha series is Motorola Xoom which is a disaster:

We were excited about the first true Android operating system for tablets and had high hopes for a mobile browser that was as powerful as the platform. Sadly, the Xoom and Honeycomb are a real disappointment. We found consistent and reproducible issues in CSS3 Animations and CSS3 Transitions among other things. We had issues where the browser either hung or crashed. Regular scrolling was slow or below full framerate. We had issues where media playback failed or performed incorrectly. At times it felt like we were using a preproduction device, but we bought our test device from a Verizon Wireless store.

I have a hunch that the latest Galaxy Tab might fare better. Sencha did like the HTML5 support in the BlackBerry PlayBook though.

With Adobe Flash now in decline on mobile devices (Adobe is no longer working on the mobile Flash player) HTML5 support is all-important for rich browser-hosted apps; I will be watching with interest for future Sencha reports.

internet, javascript, microsoft, professional, software development, Web, web authoring

Microsoft backs ECMAScript, dismisses Google Dart

2 Comments

Microsoft has posted an article on Evolving ECMAScript on its IE Blog. ECMAScript is the official standard for what we call JavaScript. The company is proposing some minor additions “to address gaps in Math, String and Number functionality as well as Globalization.” It has also taken the opportunity to take a shot at Google, which is proposing a new web language called Dart:

Some examples, like Dart, portend that JavaScript has fundamental flaws and to support these scenarios requires a “clean break” from JavaScript in both syntax and runtime. We disagree with this point of view. We believe that with committee participant focus, the standards runtime can be expanded and the syntactic features necessary to support JavaScript at scale can be built upon the existing JavaScript standard.

Dart will compile to JavaScript so there is a measure of compatibility, but if the language catches on then browsers without a native implementation will be disadvantaged.

.net, adobe, flash, professional, software development, web authoring

What next for Adobe Flash? Think runtime not plugin

2 Comments

Adobe is stating that mobile Flash will no longer be developed:

Our future work with Flash on mobile devices will be focused on enabling Flash developers to package native apps with Adobe AIR for all the major app stores. We will no longer continue to develop Flash Player in the browser to work with new mobile device configurations (chipset, browser, OS version, etc.) following the upcoming release of Flash Player 11.1 for Android and BlackBerry PlayBook. We will of course continue to provide critical bug fixes and security updates for existing device configurations. We will also allow our source code licensees to continue working on and release their own implementations.

Although this seems like a major shift in strategy, Adobe has been moving in this direction for some time. At the MAX conference last month the company was clear that most web developers can be expected to use HTML 5 rather than Flash most of the time, reserving use of the plug-in for video, games and certain kinds of application. As for mobile, all the talk was about AIR and the captive runtime, an approach similar to the iOS packager which bundles the Flash runtime into your application so that no plug-in or additional download is required.

This approach is now explicit, and I reckon we can further conclude that if the Flash plugin for mobile is being abandoned, then the Flash plugin for the desktop is also less important than before. Mobile browsing is huge, and likely to grow, so developing web pages for Flash is unattractive other than in cases where there is an easy way to direct mobile browsers to a non-Flash alternative. Flash as a browser plugin will now decline forever, which is a good thing for web standards even if it is not necessarily a good thing for web developers, who must face the challenge of cross-browser development.

So what is Flash now? It is still Adobe’s runtime, and the client for its media services, and in that role it remains significant. Thanks to Adobe’s packaging work, you can take your Flash or Flex application and deploy it to most desktop and recent mobile platforms, though not to Windows Phone or older Android devices. Could you not use HTML 5, JavaScript and PhoneGap instead? Maybe in some cases; but Flash is a richer, faster and more consistent platform, as well as benefiting from Adobe’s design and development tools.

See also my piece for the Register: Down but not out: Flash in an HTML5 world.

Update: Added official Adobe link for statement on mobile Flash.

adobe, flash, mobile, professional, software development, Uncategorized, web authoring

Adobe MAX 2011 and the future of Flash

The unstated theme of Adobe MAX 2011 last week was this: what is the future of Flash? The issue being that with HTML 5 ascendant and Apple wrecking the idea of Flash as an ubiquitous web plug-in, should Adobe be frantically retooling its design tools for HTML and apps, or does Flash still have a future?

image

The answer is a little of both; but let’s be clear: there was more Flash than HTML at MAX. What was the most eye-catching demo? It was Flash running Unreal Tournament with the claim of better graphical performance than on Microsoft Xbox 360 or Sony Playstation 3.

It is also worth noting that the touch apps demonstrated at the day one keynote were created in Flash and compiled into apps using the new Captive Runtime feature in AIR 3.

At the same time there was a substantial amount of HTML effort on show. There was the announced acquisition of Nitobi, makers of PhoneGap – though note that PhoneGap itself is heading to the Apache Foundation – and demos of the Edge motion and interaction tool for HTML5. Adobe also told us about its work on CSS Regions and CSS  Shaders. I also saw how HTML export, including partial ActionScript to JavaScript conversion, is coming in a future version of Flash Professional.

My perception is that while Adobe is serious about stepping up a gear with its HTML tools, its heart is still with Flash. That said, there is a shift of emphasis away from Flash as a web plug-in, other than when it is the “Games console of the Web”, and towards Flash and Flex as a cross-platform development platform. Adobe is using Flash and AIR for its own Touch apps, previewed at MAX.

Let me add that the new features in AIR are huge, in particular the ability to package the Flash runtime as part of your app, called Captive Runtime, and the ability to extend your AIR app with native code. Cross-platform mobile tools are a particular interest of mine, and Adobe’s offering is strong in this field, though it will never be the most efficient. Adobe is also pressing ahead with something like web workers for ActionScript, providing a form of concurrency, though this is not in AIR 3 but planned for a future release. Another big new feature in the Flash runtime is Stage 3D, accelerated 3D graphics which enabled the Unreal demo mentioned above.

Nitobi’s Andre Charland was at MAX and I could not shake off the thought that he will find joining the Flash company difficult.

image

It will be near-impossible for Adobe to be equally enthusiastic about both PhoneGap and AIR, and given that Flash and AIR are so deeply woven into the company’s products I suggest that PhoneGap is more likely to be neglected.

Take a look at Adobe’s agenda for the Back from MAX event in London next month. It is 100% Flash and Flex.

What about the MAX attendees? I have contradictory evidence here. I noticed that a session on Building mobile apps with HTML, CSS and JavaScript (ie PhoneGap) was packed out, while the session running at the same time on What’s new in AIR – and what’s next was sparsely attended. This session was repeated, which means Adobe thought it would be a popular one. I was also surprised by how few went along to hear about Flash Professional Sneak Peek: a glimpse at the future which was a fascinating session if you are interested in the future of this tool. Adobe must have been surprised too, as it was in a large room.

image

That said, a session on native extensions for AIR was moved from one of the smallest rooms to one of the biggest and was still full. There was also great interest in concurrency in the Flash runtime. Many of the attendees I spoke to saw themselves as Flash and Flex developers and there was more talk about how to fight off the perception that the tech world is moving to HTML, than of how to encourage it.

Getting rid of Flash may seem like obvious progress to someone annoyed by the Adobe updater, or who is an Apple iOS enthusiast, or who does not like the idea of proprietary plugins. It does not feel like that though if you have a browser-hosted app to maintain and enjoy targeting a single runtime rather than testing in every browser, as well as using features of Flash that are hard to replicate in HTML.

Adobe’s design and development platform is still Flash-centric, which is either good or bad news depending on your perspective.

See also Down but not out: Flash in an HTML5 world.

adobe, internet, javascript, mobile, software development, web authoring

Adobe Flash Professional to get HTML authoring features

I have just attended a session on the future of Flash Professional, the designer-oriented authoring tool for Flash, here at Adobe MAX in Los Angeles.

One feature that caught my attention is that export to HTML is coming to Flash Professional. Adobe already has a research project called Project Wallaby which converts .fla files to HTML 5, though I have heard that it is not very good. This one looks more promising, and we saw how a simple animation can be published to HTML and JavaScript and look exactly the same. Some of the key features:

  • There will be a limited ActionScript 3 to JavaScript conversion included.
  • There will be “guardrails” in Flash Professional, so that if you choose to work for HTML then incompatible options will be greyed out.
  • The exported code will use the same libraries as Adobe Edge, a new animation tool for HTML, and you will be able to open it in Edge and do further work on it there. The Edge approach uses jQuery as well as its own format for storing animations.
  • I got the impression that this feature will be in the next version of Flash Professional, which we can call for the sake of argument Creative Suite 6

We also got a glimpse of a future version of Flash Professional which will be 64-bit and use the native Cocoa framework on the Mac – but this will NOT be in the next version.

This move strikes me as significant, in that it shows Adobe’s ability to repurpose its tools for HTML 5 alongside Flash.

Does it mean that Flash is dead? That makes a good headline, but it is not the case. In fact, I have picked up some anxiety here among developers and designers concerning the future of Flash. They like targeting Flash and do not want to return to puzzling out endless browser compatibility issues, and having to limit their designs to what will work in the lowest supported version. They will have been reassured to hear about energy going into Flash development; the session I attended on concurrency in the Flash runtime was packed.

Stage 3D, the new GPU-accelerated 3D API in Flash, enables fast graphics that bring console-quality games to the browser. It will be a while before this is achievable in HTML that works across all popular browsers.

Flash is not going away, but nevertheless Adobe is in transition, and I am hearing more about HTML 5 at MAX this year than has previously been the case.

I am also seeing more focus on Flash as a cross-platform runtime that you bundle into your mobile or desktop application, using either the iOS packager or the Captive Runtime, so users will not even know that they are running Flash and will not need to download it separately.

apple, mobile, software development, web authoring

Appcelerator opens component marketplace for mobile developers

Appcelerator has launched its Mobile Marketplace, offering software components for mobile and web developers using Titanium, Appcelerator’s cross-platform toolkit for Apple iOS, Google Android, and others – though only iOS and Android seem to be supported in the Marketplace currently.

image

Developers create modules using the Titanium Module SDK, and get 70% of revenue.

I took a quick look and found it thought-provoking. I am a fan of user reviews, and one nice feature of the Mobile Marketplace is that it supports reviews and ratings. Finding out what other developers think of a particular component often involves trawling through Google searches, asking on forums and so on; a marketplace with authentic hands-on reviews has real value.

That said, when I checked out an example, LucidChart, which is a diagramming component with 5 star rating and four reviews, I was not impressed with the review quality, and puzzled that some of the reviews date from July, before the Marketplace opened. Still, developers can make their own judgment about the reliability of a particular review.

Many of the components are on a monthly subscription, on a per seat, per month basis. Some developers are uncomfortable with this model and the likely costs:

… charging such high monthly fees is a complete rip off. My entire Apple developer license only works out at $8.25, are you seriously thinking that a module is worth more than what Apple provide to developers for a fraction of the cost?

Another issue is that some of the products are not really code components, but developer services like TeamworkPM.

Some components are free though, and if the Marketplace attracts a reasonable level of traffic and interest then it could prove an excellent resource for Titanium developers.

adobe, flash, microsoft, mobile, open source, professional, software, software development, web authoring

Adobe to ship Flash 11 and AIR 3, repositions Flash vs HTML 5

Adobe has announced that Flash 11 and AIR 3 will ship in early October.

There are significant changes in this release.

  • Flash gets Stage 3D (previously codenamed Molehill), a set of low-level 3D APIs, GPU accelerated where hardware allows, which will make console-like 3D graphics and games possible in Flash. Stage 3D wraps DirectX on Windows and OpenGL on desktop and mobile platforms.
  • 64-bit Flash is here at last, supporting 64-bit Internet Explorer and other browses on Windows, Mac and Linux.
  • AIR, which uses Flash as a runtime for desktop and mobile applications, now supports native extensions for better device support, operating system integration, and the ability to speed performance-critical code or use open source libraries.
  • In addition, the AIR packager for iOS, which lets you wrap your application as a native executable, is now a feature called Captive Runtime which is available for Windows, Mac and Android as well as iOS. Users who install a packaged application will not know it uses AIR, and will not need to install or update the AIR runtime as it is packaged with the application, though it is not actually a single file (on Windows at least).

These new options make the Flash and AIR combination an interesting comparison with other cross-platform development tools, such as Embarcadero’s new Delphi XE2, which targets Windows, Mac and iOS with a new framework called FireMonkey; or Appcelerator’s Titanium tool for cross-platform desktop and mobile development. Note though that Adobe is not promising any performance improvement. This is just another way to package the same runtime.

Adobe’s advantage is its high quality design and development tools and the maturity of the Flash runtime. For application size and performance, it will likely fall short of true native development tools. The ActionScript language could do with updating, and I would not be surprised if Adobe addresses this in the next major Flash release.

But do we still need Flash? Flash in the browser is in decline, thanks to the influence of Apple and the rise of HTML 5. Adobe’s MAX conference is coming up soon, and I noticed in the schedule [Flash needed] a defensive note in some of the sessions; there is even one called “The Death of Flash” which talks about “the misinformation that’s percolated through the web over the past year”.

That may be so; but even Adobe is re-positioning Flash and recognizing the rise of HTML 5. “Customers see significant advantages for Flash in a few focused areas,” said Adobe’s Danny Winokur, VP and General Manager of Platform , in a press briefing. He identified these areas as gaming, media apps, and “sophisticated data-driven applications” – think data visualisation rather than just forms over data. “For everything else it is very clear that … HTML 5 is a mature enough technology that it is a really good solution.”

Adobe is therefore investing in HTML 5 tools as well as Flash tools, and Winokur mentioned the Edge motion design tool as well as the venerable Dreamweaver.

I asked Winokur, given that HTML 5 is maturing fast, how Adobe sees the picture vs Flash in say two years time. He replied that Adobe is actively working to advance HTML 5, but that “there will continue to be opportunities for innovation in Flash, where we can … enable new possibilities that did not previously exist on the Web.” He makes the case for Flash as a kind of leading edge for HTML, with features that eventually become part of the HTML standard.

It is a fair point, but it is obvious that the niche for Flash is getting smaller rather than larger.

Adobe has never charged for the Flash runtime, and while the Flash vs HTML path is tricky to navigate, Adobe mainly makes its money from design tools, server applications and web analytics, and while Flash plays some client role in many of these products, Adobe can tune them over time to make less use of the runtime. I believe we can see this happening.

More positively, Adobe is benefiting from the demand for rich content across both web and applications, and has just reported decent financial results, showing the company’s resilience.

Finally, everyone is asking what Adobe will do about Microsoft’s WIndows 8 Metro platform for tablets, given that browser plug-ins are not supported. Here is the answer:

… we expect Flash based apps will come to Metro via Adobe AIR, much the way they are on Android, iOS and BlackBerry Tablet OS today

though I hope this will be delivered more quickly than the promised Flash runtime for Windows Phone 7, which is not a subject either Adobe or Microsoft seems willing to talk about.

Update: Adobe has also announced the Flex 4.6 SDK and Flash Builder 4.6, which supports these new capabilities including Captive Runtime and Native Extensions, and has new controls specifically aimed at tablet apps.

adobe, internet, professional, software development, web authoring

Adobe Muse: so what is wrong with Dreamweaver?

Adobe has released a preview of Muse, a new web site design tool.

My first reaction was one of be-musement. What is wrong with Dreamweaver, the excellent web design tool included in Creative Suite? Bearing in mind that there is also a simplified Dreamweaver aimed at less technical business users, called Contribute.

Here are some distinctive features of Muse:

1. It is aimed at non-coders. The catch phrase is “Design and publish HTML websites without writing code”. Muse actually hides the code. I installed Muse on a Mac, and one of the first things I looked for was View Source. I cannot find any such feature. You have to preview the page in the browser, and view the source there. That is in contrast to Dreamweaver, where the split view shows you simultaneous HTML and visual designers, and you can edit freely in either.

2. It is an Adobe AIR application. I discovered this in a bad way. It would not install for me on Windows:

image

A curious error. Luckily I am also working on a Mac right now, and there it worked fine.

image

3. It will be sold by subscription only. The FAQ answer is worth quoting in full, as it describes one of the key advantages of cloud computing:

Muse will be sold only by subscription because it will allow the Muse team to improve the product more quickly and be more responsive to your needs. Traditionally Adobe builds up a collection of new features over 12, 18 or 24 months, then makes those changes available as a major upgrade. It is anticipated that new updates of Muse will be released much more frequently, probably quarterly. New features will be made available when they’re ready, not held to be part of an annual or biannual major upgrade. This will enable us to stay on top of browser and device compatibility issues and web design trends, as well as enabling us to respond to feature requests and market changes in a much more timely fashion.

I am reminded of Project Rome, a cancelled project which was also intended to be subscription only. Rome was for desktop publishing, Muse is for web design; otherwise there are plenty of parallels.

4. Muse promotes Adobe hosting via Business Catalyst, and if you select Publish this is the sole option:

image

Of course you can also Export as HTML. Still, it looks as if Muse is intended as part of a wider initiative which will include hosting and web analytics.

5. Muse is not a Flash authoring tool. Check out the Features page. The word Flash does not appear. Nor did any hidden Flash content appear when I exported a page as HTML. My guess: there is a quiet Flash crisis at Adobe, and the company is hastening to make its tools less Flash-centric, in favour of something more cloud and HTML 5 based. I do not mean that Flash is now unimportant. It is still critical to Adobe, and after all Muse itself runs on Flash. However it is being repositioned.

A few comments. Unfortunately I’ve not yet spoken to Adobe about Muse, but the obvious question is reflected in my heading: what is wrong with Dreamweaver? To answer my own question, I can see that Dreamweaver is a demanding tool, and that Muse, while still aimed at professionals, should be easier to learn.

On the other hand, I recall many early web design tools that tried to hide the mechanics of web pages, some more successful than others, and that in the end Dreamweaver triumphed partly thanks to its easy access to the code. Some still miss HomeSite, an even more code-centric tool. What has changed now?

Needless to say, Dreamweaver is not going away, but there is clearly overlap between the two tools.

Of course non-coders do need to be involved in web site authoring, but the trend has been towards smart content management tools, such as WordPress or Drupal, which let designers and coders develop themes while making content authoring easy for contributors. Muse is taking a different line.

Watch this space though. Even on the briefest of looks, this is an impressive AIR application, and it will be interesting to see how it fits into Adobe’s evolving business strategy.

Update: Elliot Jay Stocks blogs about the code generated by Muse, which he says is poor, and his opinion that it is too much print-oriented:

warning signs are present in this public beta that suggest Muse is very much a step in the wrong direction.

adobe, flash, professional, software development, web authoring

Adobe Edge previewed: another step towards HTML 5

Adobe has released a preview of Edge, a new tool for creating animations in HTML 5, JavaScript and CSS3.

Edge is interesting on two levels. First, HTML 5 lacks strong design tools so a new tool from Adobe is welcome. Edge is a timeline-based tool for creating animations. You import elements such as images, or create text and graphic elements in the tool. Using the timeline, you create keyframes and specify effects. Here is the designer:

image

and you can view the output right here. This is one of Adobe’s samples, created by Sarah Hunt.

image

Under the covers Edge uses the JQuery JavaScript library. Here are the includes for this example:

image

and here are the transition effects on offer:

image

Edge is not complete yet.  A future update will add a JavaScript editor, making this more interesting for application developers. There will be a documented Edge library that will let you customise and I presume interact with the Edge output. One of the possibilities that interests me is data visualisation. Will Edge support this? Adobe is not yet saying, but it would be a natural move.

Adobe already has an HTML design tool, Dreamweaver. Why another one? Or put another way, why is Edge not a new designer for Dreamweaver rather than a new product in its own right?

This is an early preview, and all things are possible. However, Adobe has a tricky positioning task, given that Edge is encroaching on territory that used to belong to Flash, timeline-based animation. In its FAQ [PDF], Adobe distinguishes its products like this:

Product Sample use cases
Adobe Edge Preview 1 Advertising, simple animations and motion design for new compositions or using existing CSS-based page layouts
Adobe Dreamweaver Websites and web applications for desktops, smartphones, and other devices
Adobe Flash Professional Immersive interactive experiences, mobile applications, gaming, premium video, advertising
Adobe Flash Builder Rich Internet Applications (RIAs) and mobile applications

This table fails to mention what must be part of the core rationale for Edge, which is working on Apple iOS, the mobile operating system for iPhone and iPad that does not run Flash content. If you view the demo page above on the iPhone 4 or iPad 2, you will find that it works fine.

Adobe’s distinctions in the table above are not particularly clear. Leaving aside the relative merits of Flash and HTML 5 as technologies, a key question for developers and designers is one of reach. HTML 5 has a reach that extends to iOS and to other devices that do not run Flash in the browser. Flash has a reach that replaces browser-dependency with dependency on Adobe’s runtime, which can be a good thing.

Incidentally, I asked Adobe during a press briefing about mobile support and also browser requirements for Edge content, but there is no official statement on this yet.

Is Adobe moving away from Flash towards standards-based HTML tools? The purpose of a table like the one above is to insist that this is not the case and that Adobe will continue to support both. Nevertheless, Edge is a significant move. A gradual decline in Flash usage in favour of HTML 5 is not necessarily bad for Adobe. Designers will use the same Adobe tools to create content for Edge as they do for Flash.

What about Wallaby, another Adobe experimental project which exports Flash content to HTML, in effect making Flash Professional an HTML 5 authoring tool? Adobe says that Wallaby and Edge are separate projects and there is no plan to have Edge import Wallaby content. Still, you would have thought that, if Wallaby makes it into an official product, some compatibility is inevitable.

image

Edge demo on Apple iPhone 4