As a free application, this ability to create a library of offline API documents would be enough to make me recommend Doc? to every Flex/ Flash developer. However, it has another feature up its sleeve that just makes it an awesome product: it has plugins for Flex/Flash Builder and Flash CS3/CS4. These plugins allow you to rapidly access the API documentation for a class you are trying to use. Continue reading ““Doc?” — a great Flash/ Flex developer tool (and its free)”
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.