Archive for November, 2008

My god…its full of stars

Its time to start making things look nice.

Last time I started with the central user focused object – the pattern – and started creating MXML components that corresponded to the object’s parts.  This, along with some temporary data structures gave me a rough working prototype of the pattern object.  It did look quite ugly however.

This time I spent moving objects around, changing layout and playing a bit with color schemes.  Since most of the pattern is data driven, allowances need to be made for different lengths of data.  This means that objects holding text and images needs to expand to fit the required screen area.  Other objects need to flow properly so text doesn’t end up running on top of other paragraphs

In AIR this means that things need to be placed in the appropriate UI containers. I had already used the Canvas container to hold sub parts of the pattern (such as the Instructions and the Recipe), but there are others that came into use such as the HBox, VBox and Tiles.  The Canvas is great, you can place any object where ever you want and it doesn’t care.  Unfortunately it doesn’t care about flow or object collisions either.  With dynamic data the Canvas can look like a real mess.  The HBox and VBox on the other hand, will only place one object in one place at a time.  Depending on which box you choose it will place objects side by side or stack them.  Either way it does take care of flow.  Tiles are another really useful container – depending on the direction, it will place things side by side (as with an HBox) until it reaches its maximum width, then it starts a new row.  By nesting the containers you can pretty much get the screen to flow any way you want.

To decide what objects went in what container, I started by drawing all the objects on a piece of paper.  I then drew an arrow next to each object to indicate the direction I wanted it to flow.

I then drew boxes around objects on the same plane.  By looking at the flow lines I can determine what container was required.  For example the entire Pattern screen needs to flow down – I want it to get longer if there is a lot of information (not wider).  This means that the Pattern Screen can be wrapped in a VBox. One of the consequences of this is that all of the objects would be stacked on top of one another as that is all that a VBox allows.  When I look at the Name, Tier and Species fields I want them to be on the same line. This means that they must be grouped in an HBox.  By continuing this process I eventually had a layout that would flow correctly as different lengths of data were added. Another thing I found was that by omitting the height and width attributes of certain HBox and VBox elements the boxes will inherit the height and width of the elements inside them (they would flow correctly).  I.e. the VBox that contains the picture and recipe will expand to fit all of the Recipe because it does not have a set height.

Another concern that I had was making the right part of the screen scroll.  Even though I have a few sections that I did want to scroll – such as the Instructions.  I had to tinker with things a log, but I eventually got just the Instructions section to scroll and not the entire page.  This was a bit of a PITA and took a lot of fiddling with the width and height values of the various containers.  At some points I had scroll bars on top of other scroll bars.  If anyone knows of an easier way to this (besides trial and error), please let me know.

Once I had things laid out nicely and flowing correctly, I started looking at themes and colors.  Eventually I will use a style sheet, but I’m still playing with things too much for that right now.  As far as colors go, I’m no Graphic Designer.  I can tell when something looks wrong, but what it takes to make it right is beyond my current skill level.  Fortunately there are some really nice tools out there to help. On of my new favorites is Kuler (yes I am Adobe biased).  There are tons of user defined color schemes available, some better than others.  My favorite feature is the Create From an Image feature.  I uploaded a picture (in this case a picture that included my parka and waders) that had the right "feeling" and it picked out the color theme from that picture – way cool.  With some minor adjustments I can use those five colors for all my objects and still have something that looks nice.

One other thing that I did was to add a new component for the Species field.  I decided that icons looked better than text and it was just a matter of doing a similar repeater setup that I used in the Recipe and Instructions components.

One complaint – As I have stated before, I am a coder by training.  I love the rich IDE environments that are provided in tools such as Eclipse.  Since Flex Builder is based on Eclipse, I believe that it should have the same rich development environment.  Missing features such as source formatting (pretty printing) and variable highlighting annoy me to no end. If someone on the Flex Builder team is listening – please add these feature in as they are in the Java developing mode.

Staring at a blank page

I launched Eclipse, created a new Flex project and got a shiny new application started. I then found myself staring at the clean grey page with no idea of where to start – call it programmer’s block. Okay, time to regroup.  In the past, with larger code based development projects (Java, .Net, etc.) I would have fallen back to the design document and started with either the main data structure/function, or some of the well defined supporting classes.  Really building with AIR is no different.  The only change is that instead of a data structure, the project is user/task focused. 

If I look back at the application structural diagram it gives me a place to start:


The central object that the user interacts with is the Fly Pattern – seems as good a place to start as any.

If I look at a typical fly pattern it consists of some simple elements (the image, fly name, tier name, notes) and some more complex elements (recipe, instructions) that can repeat. To me this means that the pattern class has a couple of support classes that contain repeating elements.  Now we’re getting somewhere. 

I created a new MXML Component to hold the pattern and called it patternDetails.  I dropped on some objects to hold the simple elements – an mx:Image for the main picture, a mx:Text for the fly name and another mx:Text for the tier’s name.  I didn’t mess around with layout and design too much – I wanted to get all of the elements together before I worried about aesthetics. Not that aesthetics aren’t important, they are one of the keys to usability, but there is no use buying wallpaper until you know how big the room is.

Next I created two other MXML Components – one for the recipe data and one for the instructions.  Both of these have elements that repeat and are quite similar in function, although they are very different in presentation.  First the recipe: this consists of a list of elements consisting of parts, materials and notes.  The number of elements in the list is not fixed as one pattern may have three items and another may have forty.  I needed a MXML object that was capable of holding such a list.

In previous projects I have used the DataGrid in its various forms. Its a useful item that can be bound directly to a data source and has a lot of built in functionality (such as sort). Its really useful for lists of data items. I tried it, but it just didn’t look right, it was a bit too rigid in its layout.  I started to look for an alternative when I came across the mx:Repeater. Repeater also can be bound to a data source, but you specify all of the item layout yourself.  It doesn’t have the built in functionality, but it does have a lot of freedom in its layout – perfect.

Since I have to consider layout soon, I would like to see how the screens look with “real” data and image.  I picked a fly pattern called a Stimulator as a typical example, but how to get the data into the application?  Eventually this will be done by reading the information from a database, but this requires developing the database structure, supporting data structure and supporting classes.  It will have to be done eventually, but for right now I just want to see something quickly. I could go the other route and just hard code everything from images to text, but that doesn’t verify the functionality of the application – it means that I would need to rebuild everything when I built the functional code.

What I needed was a happy medium – something that I could put together quickly with out a lot of support classes, but still could be easily transitioned into functional code. Objects such as Repeater can use a dataProvider attribute to specify their data source. The dataProvider can be an array of Objects and can come from any data source.  In the long run the source will be the database, but right now I can create a local array and use it to test the Repeater. So I created a temporary folder for the images and set up an ArrayCollection to hold the data locally. For example, the following is the temporary array setup for the recipe component:

One other thing to note about the Repeater.  A consequence of complete freedom of look and feel is that you no longer have some of the basic functionality that you would expect.  For example when I first created the Repeater, connected the dataProvider and populated it with some text elements it repeated everything on the same line.  It did not lay new elements after the previous one.  What I wanted was something akin to the repeating subform functionality provided Acrobat.  I eventually found that wrapping the entire Repeater in a VBox did the layout as the VBox ensures that elements get placed one after the other.

So, now I have a rough fly pattern view with real (sort of) data.  I can now start making it look nice.  Here’s what it looked like before the beautification effort:

For those interested in seeing the early source code I’ve posted it in zip format here.



Thats no moon….

As you may recall, one of the main purposes of this project is to teach a traditional Java programmer (namely me) how to develop Rich Internet Applications (RIA).  This goes beyond just learning syntax and tooling, it means gaining a deeper understanding of the possibilities of a new environment.  To that end I have been doing quite a bit of reading about designing applications for RIA environments.  The more research that I do, the more I am convinced that this project requires a fundamental shift in thinking from a code based development mind set to a more visual based/user centric model. Developers/programmers (and I include myself in this category) can easily become too enamored with our own data structures and can loose track of the user that our applications should be designed for.  This is nothing new, but it becomes glaringly obvious as more tools become accessible to a wider range of development talent.  I guess what I’m saying is that crappy user design becomes less acceptable as tools make it easier for better design. Certainly, tools such as Flex Builder make it easier for a more diverse population to build better applications.  In no way does this excuse poor system design , it just means that good system design should support a good user experience.

Rob Adams, a Senior User Research Specialist with Adobe, has written a series of Developer Center articles that I really encourage anyone developing AIR/Flex applications to read. Rob’s articles will help get you into the RIA head space and help you to start designing better RIA applications.

I finally got around to putting together the system design document for the
Fly Tying Inventory tool that I described in earlier posts. I’ve tried to keep Rob’s suggestions (and others that I have read) in mind while working on the design for this project.  Specifically, I started with the consideration of the user’s task (finding a fly pattern and associated media) and worked the design from that.  Everything needs to be considered from the point of view of the user’s purpose. See the attached BC_Requirements document, which is a light weight combination of Requirements Document and Systems Analysis and Design document.  I can get away with something lighter because I will be building most of the application myself – I can wing it with some of the design.

One interesting outcome from this user/task oriented approach is the database layout.  When I started listing all of the things that a user needs in relation to the fly pattern (the central concept of the application) I found that I had created a horribly un-normal data record.  I went through an exercise to do some basic database normalization and got it at least to a 2NF state. Getting to 3NF can be more desirable, however I find that higher orders of normality can mean that many joins are necessary for searching, which is inherently inefficient.  Because I am using AIR and will be stuck with SQLite (which doesn’t allow foreign keys) 2NF should be good enough. I already know, from past projects, that you usually need one class for each of the database tables that you are loading into memory – so the database design has a direct correlation to the application’s data structures.

In previous posts I mentioned that I will be creating an Interface Design Document as well, but it is conspicuously absent.  I did try to write one, but I found out that I didn’t know enough of the capabilities of the AIR environment to write something useful.  I’m sure a Designer could have done it anyway, but I’m a coder – I need to learn what I don’t know first. I’ll probably write one up after I play with things a bit, some experimentation is necessary.