Ted Patrick > { Events & Community } > Adobe Systems

One of my projects for Q1/2008 is a very large expansion of the Flex Directory. Today I updated the directory and added 85 new firms developing with Flex. The Flex Directory now lists over 250 companies who can build Flex applications. Before we take a look at what is next, lets take a look back at what worked and what did not.

What worked:

• Flex over XML - XML + XSL + SWF
• SEO Compatible - #1 Listing in Google for "Flex Directory"
• Simple and easy to update XML file
• Sortable/Filterable
• Easy to sign-up

What didn't work:

• No Database, just 1 XML file. It worked but it needs a backend. :)
  
• Updating a listing required submitting a listing again. This needs to be self-maintained and easy.
• Management tools - Currently the site lacks any management tools other than TextMate editing XML.
• Company detail: ScreenShots, Logo, Description, Contact Details, Location Details
• No support for developer listings or alternate types.
• Just Flex - No support for Flash, AIR, or other.

FXD 2.0 - Architecture
To start, the new architecture is a Structured XML/Flex WIKI. Basically there is a simple API for updating the URL listings and all XML stored is rendered through a Flex template. In this case I can update 1 SWF file and change the look and feel of the entire site while supporting variable schemas for all types of listings. The model is quite powerful and allows for clean SEO support, an XML API , clean urls, and compatibility with 95%+ of browsers. This architecture is something I have been working on quietly for over a year and this will be the first large scale use of it outside of the internal demo apps.

My favorite feature is that the UI is completely separate from the data and this creates some powerful side effects for managing the site. This allows me to add features to the template and have them optionally shown based on the model data. If a developer adds a <screenshot src="ImageURL" title="App Screen Shot"/> tags to their profile, the template will add a screenshot tab to the profile and load the image url in the UI. Allowing this sort of feature extensibility is really great and it makes the whole system really easy to maintain and extend. If you like someone elses profile, you can simple view source on the XML to find out the template's capabilities.

This solution is also very scalable, allowing the Flex Directory to support a larger number of page types and millions of pages. In the first edition I only listed companies and had to reject individual developers due to scale. With the new architecture the site will support many different types and allow cross-linking between the pages with clean URLs.

FXD 2.0 types:

• Companies
• Developers
• Projects
• Components
• Services
• Jobs

The cross-linking is key to allowing visitors to see relationships visually and navigate the site across the networks within.

Here are some example relationships that can be shown:

Developer "at" Company
Developer "recommends" Developer
Project "by" Company/Developer
Company "has" Projects/Component/Service/Jobs
Jobs "at" Company
Components/Services "by" Company/Developer
And more...

The cross-linking is one directional, optional within the profile, and tied into the URLs. Ideally it adds a ton of value and allows the developer network to become visible creating more value for everyone. For the market to grow we need this level of transparency. Ideally it will drive a lot of business to companies, raise leading developer rates, and allow projects to find the resources they need to become successful.

What is cool is that all these various types of information can be listed without a single change to the backend. As this is done WIKI style using just an XML model, the view can be wildly different atop the same model. A regular WIKI would embed markup with the model and result in an inconstant UI, this is not the case with a Structure Wiki. The system can display wildly different views of the same information and extend features of the UI should certain model information be present. From my initial tests the architecture supports the rapid creation of a large number of accounts supporting millions of entries. What is interesting is that this methodology is also very bandwidth efficient. As the UI is a single SWF file, it is downloaded and cached once per site visit and the base XML page data is really small (5K or less). This results in creating millions of pages where the UI is 100% cached after the first page and contray to popular belief it actually is far faster and more interactive than an HTML/JS/AJAX based methodology.

The goal of the FXD 2.0 is to make the market for Flex/Flash/AIR much more transparent. Currently many developers and firms build great projects but have no visibility in the larger marketplace. Components and Services for Flex/Flash are also not very visible. Ideally FXD 2.0 will make the market much more visible, help developers find projects, projects find the right developers, and developers find components and services to build their applications upon. It will be a great big social experiment atop the Adobe technology platform and should be a blast to build. If you have been following my blog for the past year you have seen slices of this in development (FXT, Flex Search, FX over XML, URL Matters ) but this will put the whole picture together.

I will also be building this transparently online and all work will be released open source and including the WIKI backend and all SWF/Flex projects within. Hopefully the architecture can be reused for your own projects.

Flex Directory

More to come!

Ted :)