Before you conclude the excitement got the better of me and that I simply imagined the bit about the AIR SDK, consider exhibit A: Mark Doherty. Continue reading “Greedy Adobe to put profits before developers?”
Install them and try your favourite content out with the betas.
If you find a bug, be sure to let Adobe know.
Finally, why not help spread the word by passing on details of this beta test drive via your own blog or twitter?
I want to add some more here in response to the comments so far. I thought long and hard over whether to get involved in this beta bug request as only this morning I was looking at a bug – ClassReference in nested CSS file compiled to SWF causes error – that was closed as “deferred” two years ago. Stefan Richter had highlighted it as an example of how Adobe mess up with bugs at times. The problem remains unfixed and Adobe’s communications were crap with this bug as they didn’t explain why they chose to ignore it. However, in the end I decided it would be wrong to focus on such negatives at the expense of the great stride Adobe have made toward openness.
They have a open bug reporting system. A lot of the flash development environment is open (the whole of Flex Framework for example.) Part of opening up to the community involves inviting the community to give back to the project, both in terms of bug reports and bug fixes. Adobe have frequently highlighted the fact that people are welcome and encouraged to not only report bugs, but to help fix them too. So to those that complain bugs remain languishing unfixed for long periods of time, I have a simple question for you: have you tried contributing to the openness of Flash by helping fix that bug?
As anyone who has been involved in software development over the last couple of decades will know, everyone once used to slavishly follow the waterfall method of software development. Projects were consistently late, over-budget and of poor quality. An endless succession of solutions to solving these problems were suggested, with little success. Then one day, the penny dropped and it was realised that the the waterfall method itself was to blame. It is a crap way of developing software; this is well recognised today. Instead of the design, implement, test, ship step approach to development, agile methods, such as Scrum, are growing in popularity. The reason is simple: agile methods are far more likely to deliver projects on time, in budget with a high quality value.
Given this, I was excited to see a work flow tool appear on Adobe Labs, called WorkflowLab and eagerly installed it to see what the tool would offer. To say I was disappointed would be a gross understatement. I was actually shocked by what I found.
The first – and relatively minor – problem was the poor user experience it offered me as a Windows 7 user. Rather than use the Windows chrome, the developers have opted to implement their own chrome. As a consequence, it lacks the nice drop shadow that “proper” windows applications have. It doesn’t support the new Windows 7 window resizing controls (ie dragging on the titlebar when maximised didn’t cause it to resume its non-maximised size). And it basically plain looks crap as it sits amid a sea of aero glass-decorated programs. My guess is that the developers use Macs and did no Windows 7 UX tests. As the latter has been freely available via the beta programme for months now, the developers have no excuse for this.
The second – and way more important – problem can be observed in the screen shot below (click on it to see the full size image). What you see is a supposed “best practice” work flow for “InDesign to Kindle Store”.
The developers seem to seriously believe that completing the layout before previewing the result is “best practice”! And lest you think that this is a one-off, even the “Workflow Behind WorkflowLab” work flow show the classic design, develop, test, release waterfall approach and sells this too as “best practice”.
In case you haven’t worked it out by now, I strongly feel this is a rubbish application, full of bad work flow advice. By itself, this wouldn’t be too bad, but this is an Adobe-endorsed product that is supposed to sell the use of Flash Catalyst in the development work flow. Catalyst has come in for criticism from some developers as the beta releases of the product only support one-way design -> develop work flows. I had assumed this due to it being a beta and that the final release would support circular, iterative, development. WorkflowLab opens up a worrying possibility though: that Catalyst will only ever support this one way flow, and Adobe are trying to con the world into thinking this is OK by presenting a failed work flow method as “best practice”.
Amidst all the excitement of deluded fools thinking now was their chance to make millions selling iPhone apps without having to learn “real” programming, the real big announcement seemed to get missed. Reading through Adobe’s FAQ on the matter, two important things stood out for me:
- A version of the Flex/ AIR SDK is to also to be released that will let Flex Builder (and presumably other developer tool) users to compile up iPhone apps.
- Those tools will run on Windows.
Until now, the iPhone app developer has been faced with a huge initial cost hurdle of having to buy a Mac. The reason for this is that, until now, only two possible solutions to developing iPhone apps existed: Apple’s own objective C development environment and MonoTouch. The latter is a .NET development tool for compiling C#, IronRuby etc into iPhone native applications. It, like Apple’s own tools, only runs on OS X. Also MonoTouch costs a lot of money, whereas the Flex SDK’s tend to be free. This opens up the possibility that Apple’s “iPhone development kit for Windows” may well be free too.
The FAQ suggests there will be compromises. My reading of it is that one cannot test the apps in Apple’s iPhone simulator, only directly on the phone itself (this applies to Mac users too) and I don’t think the normal set of iPhone APIs are accessible either.
Obviously a lot of this is speculation. A public beta of CS5 is due out by the end of the year though so we will know for sure within the next three months.
Toward the end of the keynote, we were at least treated to some sneak peaks at upcoming features in the next release of the Flash Pro authoring tool, including better integration with FlashBuilder. There was also a hint that there might be news on Flash Player 10 finally appearing on smart phones (though presumably not the iPhone) at MAX.
Next up was a presentation on AIR by Mike Chambers. It was a curious mix of self-promotion of his as3corelib project and some details on features coming in AIR 2.0. The latter is to gain built-in support for detecting removable drives being mounted/ unmounted and a new native application mode. The native mode will be built as a .exe (or the MAC equivalent) and can communicate with other native applications via stdin and stdout pipes. This seems an odd solution when the likes of Mike’s own Command Proxy project offer a much richer solution already. I guess we will have to wait for more details from MAX to understand the solution better.
The only other session of note – in this developer’s view – was a session on Spark by Mike Jones. Sadly Adobe have dumped the great name “gumbo” and replaced it with the far more boring “spark” for their new skinnable component set. The session described the current state of the spark components (subject to change of course as it’s all still in beta). Despite many criticising the namespace in CSS solution Adobe came up with to support both halo and spark in the one application, I personally think it’s a very nice solution. Catalyst remains a odd one. At the moment it just doesn’t work to my mind: it is too product-skin focused and only really goes one way from designer -> developer. I fully agree with Mike’s hope that the final product better support general (and custom) component skinning and that it better support a two way design/ develop workflow.
Tomorrow has far more developer-orientated content than today, so hopefully should prove a more fruitful day for me.
By far the least interesting Wave, Microsoft Wave is a UK-based advertising portal for new-ish Microsoft products and services. As ars technica puts it, “Microsoft Wave: yet another Microsoft site about Microsoft”.Not very interesting at all therefore.
Adobe Wave is a still-in-beta product that bigs itself up thus:
When a friend posts a status update or there’s new content on your favorite site, be the first to know. Adobe® Wave™ software gets the information you care about right to your desktop. Click on the Adobe Wave badge on a website you want to follow and you’re ready to go. Best of all, you’re in control: you choose which sites can contact you. If you’re no longer interested, turning it off is a click away — Adobe Wave does not share your email address with websites.
Now it might occur to you, as you read the above, that RSS already does this. Such thoughts certainly occurred to me. Even the idea of having a central server that aggregates all updates seems nothing new as feed aggregators have been around for a while too.
Unlike RSS though, content publishers have to sign up with Adobe to get their content published. If this service can persuade the likes of Facebook and Twitter to join up, along with news websites, blogs etc, then one might be able to do away with multiple readers and just use the Wave desktop client. That would be a great step forward.
I’ve signed up to be an Adobe Wave publisher. If approved, I’ll write another piece later going into far more detail on Adobe Wave.
If Google’s plans with Google Wave take off, then it is safe to predict that this wave will swamp the competition and become the de facto wave of the future. In a potentially classic case of disruptive innovation, Google Wave seeks to re-write the rules on electronic communication. It seeks to be what email could have been if invented now, rather than 40 years ago. It aims to be email, instant messaging, social networking, blogging etc all rolled into one communication channel.
To play the devil’s advocate, Google Wave will not likely replace email. Email remains the dominant electronic communication medium because its standards are completely open (despite Microsoft’s best efforts) and anyone can set up an email server. Whilst Wave looks brilliant, it is likely to need the involvement of Google’s servers. As history shows us with the likes of instant messaging, such restrictions are like a red rag to a bull to many and fragmentation is likely.
Google Wave is something to watch, and hopefully I’m going to be eating my words in a few years. Email is past its retirement date and we need a replacement. Maybe Google Wave will be that replacement.
Flash Builder 4
This is the new name for Flex Builder 4, as Adobe feel the Flex moniker was putting AIR and pure As3 developers off using it. The beta download is for the “Premium” version. According to the Flash Builder 4 FAQ on the Adobe Labs site, this is a name change from the fully-featured Flex Builder’s “Professional” tag to avoid confusion between Flash Builder and the Flash designer program, Flash CS4 Professional. Giving the Flash designer package a proper name would have caused a lot less confusion, but at least they have given it a bit of thought.
Flash Builder 4 can be installed as a stand-alone application alongside an installation of Flex Builder 3. So it is possible to test out the beta without losing one’s production environment. Everyone can enjoy a 30 day trial, but you’ll need a Flex Builder 3 license key if you wish to use it longer.
Flash Catalyst 4
A new addition to the Adobe stable, this tool is designed to fill the gap between Flash developers and designers in a way that the Flash designer program couldn’t. It allows the designer to turn their static picture designs into MXML code, which in turn can be used to skin the new Flex 4 components (sadly the term “gumbonents” has inevitably been dropped as the new components of now Spark components, rather than Gumbo ones.)
Having installed the beta and experimented with it for twenty minutes or so, my immediate reaction is one of “eh?” It doesn’t seem very intuitive to this developer. The tutorial info on the Adobe Labs is going to be essential reading.
What seems odd though is that there seem to be no plans to rename the Flex SDK at the same time. The Flex SDK is equally inappropriately named as it contains all of the core Flash classes, the compiler, ASDoc generator etc, as well as the Flex classes. Also without a change to the Flash Pro designer tool, confusion will continue to reign as Adobe will have two products called Flash Pro and Flash Builder Pro respectively. Such a half-baked name change smacks of some poorly thought-out marketing decision at too low a level within the company.
Another oddity of the name change is with regard to trademarks. According to the Adobe website, the fully qualified name of Flex Builder is the ridiculously cumbersome Adobe® Flex® Builder™. Presumably Adobe will try to slap a trademark on Flash Builder too. I’m no lawyer, so may be wrong here, but I suspect that as existing products using the name Flash Builder have been around for years, the TM on Adobe’s Flash Builder will mean little more than “Totally Meaningless”. See a4desk.com and the flashbuilder tool on tucows for example. Third party software houses will presumably therefore be free to use the term in their products too. Given how anal Adobe normally are over trademarks, I’m surprised at the name choice therefore.