|[ LiB ]|
A key element to any application is data. Data can download from an outside source or be input by the user . Putting the data in order and making sense of it is the developer's job. If users wanted raw data, they'd read a dictionary or page through reams of database records. Although users may want options as to what data is presented, they expect the computer to process that data for them. Chapter 4, "Working with Complex Data," discusses many ways to arrange and structure data to make processing easy and efficient for you, the developer. Chapter 5, "Presenting Data," covers ways to present the data in a lucent manner for the user to digest.
When handling any data, it's best to carefully keep your programming code and presentation graphics separate from the raw data. Ideally, you will be able to modify the data without touching the code. If nothing else, your programming must adapt to expected changes to the data. If you build a tool to search an employee database, for example, it should continue to work even when new employees get hired . It's like you know employees will be added, so you need to plan for that. Also, you'll often have to start programming before the final content is available. Keeping code separate from the particular content means you can swap content without breaking your code. Figure 3.1 shows the folder structure I used for a project. We stored language-specific images in their own folders.
Code data separation also applies to presentation style and content. A word processing program would be pretty lame if you got different words by just changing a font style. If your application is easily skinned , you'll be able to change the colors and layout without affecting the underlying code (or particular content). Having said this, I think the nature of your content should be linked to how it's presented. In fact, changing fonts can affect the way a message is perceived. In such cases, I'd just say the "content" includes style attributesso they can't really be separate. In any event, it's best to attempt to keep presentation attributes independent of code.
It's a bit of a fantasy to expect to recycle your code from one project to another, but not entirely impossible . Instead of investing undue stress to write the ultimate piece of code that never goes out of date, it may be more efficient to concentrate on your core objectives. I recycle pieces of code all the time. So, the more you can modularize and make code that's separate from your specific application's data, the better. In any event, I've yet to develop an app that can be skinned for a different client with absolutely no touch-ups required. Aspiring to this goal is worthy nevertheless.
Figure 3.2 shows two similar-looking projects side by sideone for a winter greeting card, one for a baby congratulations. Even in the nearly duplicate process, however, a fair bit of tweaking was necessary. (You can see a version of this app at www.phillipkerman.com/card.)
Regardless of how the user ultimately views the data presented by your app, the way that data is organized is entirely up to you. What goes on behind the scenes is unimportant to the user. It's like a bouquet of mixed flowers. The recipient doesn't care whether the flowers are grown in rows and columns inside a boring greenhouse (in dirt no less!). It's the final presentation that users care about. In Figure 3.3, you can see data organized in a way only a programmer could lovebut, then again, the programmer is the only person who ever sees it.
As a developer, you can structure the data however you want. In simple terms, structuring data is deciding whether you're going to have 10 rows of 3 columns each or 3 rows of 10 columns. Obviously it's more than an arbitrary decision. However, it's a common mistake to squeeze data into the narrow view the user will ultimately see. For one thing, you'll often need to maintain data the user never sees (say, a list of passwords). You can actually think of it as bad code data separation to match the underlying structure to how the user eventually sees the data presented.
One notable exception to this "developers preference" rule is when working with an existing legacy data source. Even when you must work with a fixed data source, however, you can process the data to reorganize it in whichever way you wanteither after it arrives via Flash or even by some outside tool such as a database that imports the data, processes it, and then exports. The key is that because you're the one who has to get a handle on the data, it should be formatted to your liking.
Another consideration is network efficiency. You don't want to download the entire Oxford English Dictionary just because you think it might be useful. However, you may find situations where keeping a cache of related data can actually reduce network requests . The topic of structuring data to reduce bandwidth comes up when using the Flash Communication Server (covered in Chapter 8, "Foundation Communication Server," and Chapter 9, "Advanced Communication Server").
I keep saying organize the data how you prefer, not necessarily how the user will see it. The flip side of this is you don't want your data structure to influence the layout. Organizing information for processing has a different set of objectives than how the data is presented. Even if programmers are doing the layout, they should think about user needs first.
Originally, I had a single chapter for both organizing and presenting data, but there was just so much to say! Chapter 4 actually covers a lot more than just structuring data. Namely, you'll see many ways to process and sort data. But it's not until Chapter 5, that you'll actually visually present the data. It's sort of like how the typesetting stage culminates months of prework organizing and writing a manuscript. Provided the groundwork is in place, presenting data can be pretty easy. That's not to say, however, that it's just a matter of putting a pretty face on the data.
Presenting data involves all kinds of visual vehicles. Naturally, text is the primary way to display data. However, you also can use simple graphics to represent data. For example, a graph can often consolidate an enormous amount of data into a small space. Graphs also enable you literally to see things you could never derive from numbers and text.
It's actually possible to analyze data and present the results in subtle or nonvisual ways. For example, you could have a sound effect with its volume matched to some data. Or, you could change the rate an animation plays to match a number. In this book, you won't do these specific tasks , but when your data is available in an organized form, it's not tough to extract just the parts you need.
Before turning to getting data into and out of Flash, let me say it's not like you're lying when you show your user only a small snippet of all the data. It's more like you're editorializing. Again, if users wanted the raw data, they wouldn't need your app. When you maintain data both behind the scenes and onscreen for presentation, it's like you're purposely filtering information for the user. This isn't a bad thing. Naturally, you probably want to give users a way to drill down for more detail, but being concise is a challenge.
|[ LiB ]|