What are the roles on a Flex/Flash RIA dev team?

There are many roles in building a Flex/Flash-based RIA. Some are common to building web apps in other languages. Some steps are specific to Flex and Flash, Let’s cover the range of these steps, as well as who typically performs them. I say “typically” because you may not have the budget for an 14-person team....you may have four people which have to cover many bases. Here we go:

1. Someone to organize the work effort, track progress, coordinate the backlog with business stakeholders, make stuff happen, and keep the big picture. This is typically a Project Manager.
2. Someone to lay out information architecture and interaction design in the form of wireframes. This is typically the job of an Information Architect or an Interaction Designer, however, I’ve seen Business Analysts perform this role.
3. Someone to create visual design comps which incorporate the font, color palette, iconography and image assets. This is typically a Visual Designer.
4. Someone to write user stories and acceptance criteria. This is typically a Business Analyst, but sometimes falls to the job of a Project Manager or IA.
5. Someone to slice up the visual comps and churn out image assets. This is a typically a Visual Designer.
6. Someone to create the CSS. This is typically a Visual Designer
7. Someone to incorporate the image assets into a .fla which can be imported into a Flex project. Typically this is a Flex developer, unless you have a Designer that is highly comfortable bridging creative and technical. Next year, when Flex 4 (aka “Gumbo”) and Flash Catalyst are released, the Designer-to-Developer hand-off will become more streamlined. In the meantime, this hand-off can be a clunky affair depending on the skills of the players involved.
8. Someone to lay out the base UI structure in MXML. This is a Developer well versed with the out-of-the-box components and their features/constraints.
9. Someone to architect the overall design of the presentation tier. Most teams will use one of the popular Flex frameworks like Cairngorm or PureMVC to streamline this process. For large projects, I’ve seen this responsibility fall to the Architect. For small teams with 2-3 really sharp Developers, they will share architectural responsibilities.
10. Someone to architect the messaging layer between the presentation tier and the back-end. At some point, a decision will be made as to whether the team will use HTTPRequest, JSON, XML, AMF, BlazeDS, LCDS, etc. The contents, format and periodicity of the API will need to be specified. This typically falls to whomever is architecting the back-end, in conjunction with the Flex architect.
11. Someone who loves to create custom components, manage state, and write business logic using Actionscript. This is usually done by a Senior Developer or Architect who has been around the Flex for awhile and has a deep understanding of OOP from a past life (e.g., converted Java or .NET studs).
12. Someone who knows how to use animations, transitions and maintain visual integrity during a browser window resize. This requires a Senior Developer with experience with Flash and Flex.
13. Someone to code back-end functionality, implement the physical data model, and other server-side “stuff”. For simplicity’s sake, I’ve lumped these together into a generic category because there will many nuances based on your back-end technology choice.
14. Someone to test implemented features. This could be a dedicated QA Analyst, a Business Analyst, or Project Manager.

OfficeArrow keeps growing by focusing on users' needs

In my email inbox was a holiday greeting and newsletter from one of our clients, OfficeArrow. While reading the newsletter, I reflected on the incredible journey this company has taken in the past year.

This time last year, OfficeArrow was in the concept stage. There was no website. The company had four full-time employees and several whiteboards full of ideas.

Enablus had been brought in to lead the User Experience Design for their site. We completed one focus group to identify segments in their targeted audience and to unearth critical versus nice-to-have requirements. In mid-December of '07, there was a flurry of IA design and wireframing to construct a narrative for why OfficeArrow would become important in the hearts and minds of their user base. The next goal was to validate our wireframes with a second focus group in early January.

Fast forward to today. OfficeArrow is a thriving community for office professionals - defined as administrative assistants, office managers, and event planners. The site has over 92,000 registered users (plus the thousands of lurkers who never register). As mentioned in a prior post, this rate of growth is above average. How did OfficeArrow accomplish this?

1. They know their audience and have segmented it appropriately. During the first focus group, we identified three distinct groups of users. Two of these became primary personas, the third was placed on a backburner for later development.
2. They narrowed their feature set to focus ONLY on the needs of the primary personas. On the original whiteboards were many (seemingly good) ideas. However, after refining the critical requirements for the primary personas, we reduced the scope of Release One.
3. They have dedicated resources to seed the site with content and evangelize the community. Robert Ball, the CEO, made a early decision to hire content specialists to seed the site during the early months. All of the content contributors are former office professionals (e.g., they have walked in the shoes of their users). Eventually, the site reached a tipping point where a majority of the content is user generated, not staff generated.
   

Hooray for our clients - OfficeArrow and Spectrum K12

It has been an exciting month for two of our clients - OfficeArrow and Spectrum K12 School Solutions. Both achieved huge development milestones.

OfficeArrow passes 50K registered users in 5.5 months.
OfficeArrow is a social networking site aimed squarely at the needs of Office Professionals, such as administrative assistants and office managers. The site launched on May 1st of this year. We are proud to announce that last week, OfficeArrow surpassed the 50K registered user mark!

50K in less than 6 months is a significant acquisition accomplishment. To provide a comparative, here is a extract from a chart found in a March ‘07 issue of Fast Company of other Web 2.0 sites:

• DEL.ICIO.US took 16 months after launch to get to 50,000 users
• DIGG took took 5 months after launch to get to 25,000 users

What makes the OfficeArrow metric more compelling is that it serves a tightly-focused audience, whereas DEL.ICO.US and DIGG serve an extremely broad demographic mix.

Spectrum K12 secures $7.4 Million in funding.
In the midst of the credit market deep-freeze, Spectrum K12 lands a significant round of funding. I’ve mentioned Spectrum K12 in a prior posting, hinting at our design collaboration on an up-and-coming product release. The solution, called EXCEED/RTI, was announced to the public on June 30th. Since then, the market feedback has exceeded (no pun intended) our expectations - school districts are clamoring to participate in the initial rollout.

Response To Intervention (RTI) is a hot trend in public education. In a nutshell, RTI is a framework of practices and techniques to quickly identify “at-risk” students and implement a structured program to prevent their academic failure. RTI relies heavily on data capture, both from initial diagnostic tests and from constant “interventions” (e.g., twice-a-week coaching sessions to increase reading comprehension). The Spectrum K12 EXCEED/RTI solution is designed to help teachers, principals and administrators automate the workflow, student progress monitoring and district level reporting associated with RTI.

RTI is a potential game-changer for the US educational system. Luckily, the group of investors participating in this fundraising round agree. This $7.4 Million raise will help cement Spectrum K12’s leadership position in this market category.

Saw that one coming - MS Office on the web

ReadWriteWeb nicely summarizes the product announcement by Microsoft to offer web-based versions of Office. Its about time. We predicted this strategy back in March.

What was missing from today's announcement were two aspects:

1. An offline version of Silverlight - similar to Adobe's AIR. I can write a Flex app and have it run (using AIR) in a disconnected mode. Can't do that yet for Silverlight. Until offline Silverlight is figured out, this will stymie corporate users who still want to jockey around with PowerPoint while sitting at 30,000 feet.
2. An ad-supported, free version. MS could mimic the GMail strategy - give away a scaled down version of Office for free in exchange for ad space. MS paid alot for aQuantive, one of the largest ad serving networks in the world. How about some business unit synergy???

Advice to SaaS providers: stick to your knitting

Ed Sim, of BeyondVC, recently posted on how the larger SaaS providers encounter sales process issues as they break into the enterprise sector.

The issue Ed raised is how SaaS providers have had to morph their sales approach to mimic the traditional approach employed by large on-premise software giants such as SAP, Oracle, and Microsoft. In other words - dedicated sales teams spending long sales cycles to pitch to key business-unit and procurement executives. This is a far cry from the viral marketing approach where the goal is to entice the direct user to give your software a try for 30-60 days free of charge. Top-down versus bottom-up.

It is easy to understand the motivation for a SaaS provider to lust after the enterprise space. Salesforce.com is of the size where achievement of quarterly growth targets can be difficult if it constrains itself strictly to the SMB market.

Using Salesforce as an example, going after the enterprise with your standard SaaS offering is a not always a smart move. The Salesforce value prop is predicated on two factors; (1) its "no-server-required" deployment model, and (2) how its functionality targets the needs of the SMB salesperson and SMB sales manager. While the enterprise is hip to notion of cost savings with a SaaS deployment model (factor #1), the other side of the value prop falls apart because the software is geared towards the needs of SMB, not the enterprise. Sure, there are similarities in the functional needs of "Bill." a sales manager for a 14-person manufacturer's rep firm, and "Sally," one of 3 divisional managers working leading a 2,000 person sales force. Then again, there are vast differences in how Sally and Bill manage their respective sales teams.

We echo Ed's advice to stick to your knitting. If your app is geared toward a certain audience, then don't try to over-reach into what you consider to be a tangential segment of the market. Salesforce has, for the time being, avoided painting themselves into a corner by providing a Platform-as-a-Service model (Force and Appexchange) that allows extensive customization to become a better fit for the enterprise. However, they are also a bit of an anomaly because unless you are publicly traded, you probably won't have the necessary capital to mimic this strategy. Thus, "stick to your knitting" and focus on your primary and secondary personas.