I've worked at all the labs on Tuesday, and I'd like to provide some feedback before today's feedback call.
I had hoped to spend less time on the labs, but in order to carefully follow all steps and provide feedback on the lab instructions I've actually spent the whole day (including the unavoidable emails and phone calls from colleagues, partners and customers).
Honestly I must admit I've been quite impressed by the quality of the labs. I've found only a few typos and only a few relevant bugs in LiveCycle, which were mentioned in the docs.
I've already provided detailed feedback on the lab documents in this forum, and here I'd like to comment on the format and content of each lab.
This is the best introductory lab document, with detailed step-by-step instructions that could be followed by anyone who has never seen LiveCycle.
The document for this lab is a mixture of instructions and notes on the subject of the lab. Some parts of it do not involve building anything, but just reviewing existing assets to understand their function. I'd prefer a clear "step-by-step" doc like 1, and maybe a separate doc, or an appendix, for general notes. It wasn't easy to follow the doc alongside with its more general notes, and I've ended spending as much time reading the doc as I've spent carrying out the actual exercises.
This document is another good step-by-step doc. Maybe the content is not as good as its format, more about this below.
This lab is the most complex,and while the format of the doc is very good, probably the amount of content makes it more difficult to detail every single trivial step. As I've pointed out in my annotations, often there are missing steps even though those are just trivial steps that people would likely assume anyway.
All content is both introductory and focused on the new features in ES2, a really good choice of subjects
The content covers a lot of features and, considering that the Guide Builder in ES2 is entirely redesigned, it can't obviously cover everything. Probably, as its format shows, there is even an attempt to include a bit too much stuff for a step-by-step lab. My overall feeling, after completing successfully the lab, was that I've done more in the lab than what I have properly learned through it.
I felt that the content is just too trivial. It's the kind of exercise that leads to a sense of accomplishment (look at what I've built!) even though the actual activity required is changing a couple of lines and doing a few copy and paste regardless of a good understanding about the applications being built. This is a pretty common limit of any Flex demo, and I'm never sure about the actual point of pseudo-exercises like the "build a Flex app in 10 minutes" which can be easily done by anyone without really learning anything. An audience of developers would not be impressed because they could easily think of a "build a * app in 10 minutes" with any language or environment currently in use, while usually there's not much emphasis on specific Flex features or the "engaging" side of it. Flex, IMHO, is not much about RAD, which was a keyword in the 90s and now it's assumed by any current development environment, from Apple to Microsoft and even Java in Eclipse, but it's about rich, reach and engagement and a "web-like" mixture of declarative and procedural languages. In this specific case, moreover, the exercises don't really lead to an understanding of the overall Mosaic architecture and components, considering that most key assets are already pre-built.
This is the best document for the choice of subjects and the amount of information it conveys. There's a new key feature of ES2, multi-user tasks, and some traditionally underestimated features of ES like event and exception handling. The only shortcoming is the section about custom components. Like the RIA lab, it involves just a few trivial operations and it covers only the tip of the components "iceberg". Anyway it would be impossible to cover detailed component development in the same lab, and I believe it would be great to have a dedicated lab just about component development. This remains still the most underestimated and the least documented part of LiveCycle, while most real-life projects involving LiveCycle include the development of custom components (often poorly built for lack of knowledge and documentation).
Finally, a few notes about the image. It's really great to be used with ESX or any hardware with more than two cores and more than 4GB RAM, but with the current standard specs for a SE laptop (which are usually far better than the average partner machine...) it is hardly usable. The main thing I would change would be switching back to a 32-bit guest OS. I know we might want to emphasize 64-bit support, but I'd keep that just in our slides and/or talks. Moreover I'd like to see a tuned image requiring the least reasonable amount of resources, maybe with expanded EARs and WARs to let it boot faster.
Thanks a lot to all people involved in building these great labs!