| Developing the Blackboard
Group Management application was an interesting experience,
one from which I and the other developers working on the project—John
Bennett and Tim Chi—learned quite a bit. This article explains
the process through which we created the application, from the definition
of our goals all the way through the final development process.
The Goal
The goal of the Blackboard Group Management application was to
provide a web-based GUI that would allow instructors to assign
students in their courses to study groups as well as to manage
certain aspects of those study groups (mailing lists, online file
sharing, etc). There was already an HTML-based version of the
application but it was extremely cumbersome, particular when classes
numbered in the thousands of students. The Macromedia Flash MX
version needed to provide all the functionality of the HTML version
but be smaller, faster, easier to use, and provide a lot more
functionality.
The Constraints
Along with the these goals, the Blackboard Group Management application
also came with some very tight constraints. In particular, the
application needed to be as small as possible and had to be developed
extremely quickly. In fact, most of the development needed to
happen within the span of a single week.
The Process
In order to make the development process fit within the time constraints,
we immediately chose to base all back-end integration on Flash
Remoting. With this in mind, John, Tim, and I locked ourselves
in a room for the majority of a day and hammered out exactly what
the API on the back end would be. This meant mapping out each
method, what it was expecting, and what it would return. At the
end of the day we had a full specification of each method that
would exist on the server as well as how the application would
integrate into the Blackboard system (passing user IDs, etc.).
During that time we also wireframed the application from start
to finish. Our wireframes consisted of each screen of the application
along with detailed information about what each interface element
would do and how they would interact.
After this the members of the group went our separate ways to
do the development. Once we were finished with our respective
parts of the project, we reconvened (this time just online) and
spent a few days working out a few minor bugs until the application
was complete.
The Architecture
After the first day that we spent hammering out the API and wireframes,
I sat down to teach myself Flash Remoting. I knew the basics of
how it worked but had never actually used it to create an application
before. Because I knew I would be changing my code around quite
a bit, I wanted to make sure it was as insulated as possible from
the "GUI part" of app. Consequently, I wrapped all the
server-integration code into its own ActionScript class. This
way, as long as I kept the interface to the class the same, I
could shuffle its guts around to my heart's content.
The other advantage to placing the server connectivity code into
its own class was that I could test that section totally independently
of the rest of the application. This let me create a few FLAs
that would automatically test all of my class's methods for me—which
proved invaluable as I was debugging.
After getting that class out of the way, I had to start building
the actual application.
First off, the application is based on using the frames of the
main timeline as the states of the application. For example, frame
1 is the main screen and frame 10 handles the group editing screen.
From here I mocked up the interface for each state using components.
Essentially, the app stayed in its "ugly" state until
it was nearly complete; it was only then that I skinned the components
and added the background artwork. Once each component was given
an instance name and had the name of its callback defined, I looked
at the customizations that were going to be needed for some of
the components. In particular, there are a number of list boxes
in the application that display multiple columns of data as well
as provide certain functionality like sorting on columns and tooltips.
All of this functionality was wrapped up in custom items for the
list boxes (the listbox component supports this via its setItemSymbol
method).
On the whole, the majority of my development time was spent creating
these custom symbol items—primarily because there wasn't
much documentation available at that time on creating custom symbol
items. Now there are a number of articles on this topic, available
both in the DevNet and on third-party sites as well.
The next stage of development consisted of creating the callback
methods for all the components. Finally, each "state"
of the application had an initialize method defined in it that
did the majority of the work; this is where all the business logic
was defined. Interestingly, this stage of development went along
quickly. It consisted mostly of enforcing rules about double-checking
the user's actions and keeping data in the application in sync
with the server.
As you can see, the actual app is a bit of a hodgepodge of object-oriented
and procedural code. In fact, it was the ability of Macromedia
Flash MX to work well with either or both paradigms that allowed
this application to be built as rapidly as it was. By creating
particular parts of the application as classes, I was able to
keep that code insulated from the rest of the application. Then
by writing the majority of the business logic in a less structured,
procedural manner, I was able to finish the application quickly.
Had the application allowed for a longer development cycle, I
would have definitely made it more object-oriented and generally
more organized. Even so, I feel that being able to modify my preferred
programming style with Macromedia Flash MX in order to meet a
tight deadline highlights its inherent flexibility and power for
use in web application development.
|
