1 person found this helpful
Try putting an "if" for the last conditional and see if you still always land there. It may be a case that you don't satisfy any of the conditionals and the missing "if" lets the last play thru.
I may not be following the design, but you might try a different approach to this rather than using conditionals. Just have each selection assign a string value to a variable, and when whatever option is clicked to finally display something just use the selection strings to build the frame label... sorta like...
mcContent.gotoAndStop("slide1"+"4x"+"Epithelium"); // just using the variables
I like that idea Ned--one question though, how do I set up actionscript so it recognizes something like 'slide1 + 4x + epithelium' but then clears the 'tally' so to speak if the user then clicks on 10x?
1 person found this helpful
You'll have to make some decisions regarding logistics in terms of the user experience. Consider that your at slide1 + 4x + epithelium, and you click 10x... why did you do that? I'm not challenging it, just wondering what your expectation would be for clicking that. If it were me I would be expecting to see slide1 + 10x + epithelium if I made that choice. However, if I then selected slide2, my assumptive nature (as a designer, not a user) is that there may not be an epithelium choice for that set of slides, so maybe selecting a new slide option resets the rest and clears the view in some way.
The slides work stepwise, so going from epithelium + slide 1 + 4x to
epithelium + slide 1 + 10x would be a logical choice. Going from epithelium
+ slide 1+ 4x(or 10x, or 40x) to epithelium + slide 2 would always show the
4x magnification (so the 4x in all instances is the 'root' image).
It's set up like there are 3 roots--cell type, connective tissue,
epithelium(these are the broad topics) and within each of those there are
10-20 slides, so a total of 30-60 unique slides. Then, within each of those
slides there are multiple magnification levels, 4x, 10x, 40x. Total, there
are going to be between 90 and 180 unique images.
I can't provide a solution for you but I would recommend following something along the lines of what I suggested. You should (hopefully) be able to define a pattern for user interaction that a simple coding scheme can support. Otherwise, if you have to code uniquely for each slide you'll be getting bogged down in managing the code.
First, I would like to state that what Ned says about looking at your application from user perspective is an invaluable and very often underappreciated necessity when software is developed.
I am not sure I can provide you with an immediate practical solution but what you are dealing with is a very common situation. As I understand what you are trying to do, on a conceptual level, is to branch user's experience in an environment where possible outcome depends on someone else's unpredictable decision.
Well, I suspect that you got into the same trap as many developers do. This trap is first to create interfaces (as in UIs) and then to decide how it will play out. From my experience it is a backwards approach.
In applications like that (as in 90% of applications) the first question one needs to ask is "What are my data and its structure?" Believe me, this is the single most important thing to do before writing the first line of code. Data is a skeleton of every single application I have ever developed.
There is a concept of separation of information and presentation layers in software development. In the nutshell it means, among other things, that mechanism of data management is an independent area of code. Independent means that it is totally unaware of how it is going to be used. Thus, there is supposed to be another mechanism that reads information and decides how to apply the data or pieces of it to the application - UI in particular.
So, once data part is taken care of, you may already have a very clear idea of how to deal with the visuals and user experience progression.
In your case, I would organize data in some structure that describes parent/child relationships. It can be XML, Objects/Arrays, etc.
Next step would be to write a set of functions (preferably classes) that react to user interaction with UI and request directives from the data based on user's actions. In a concept, say, if a click came from layer 10, object 3 --> show all the children of object 3. Or there may be different kinds of clicks – one can request drill down to the children, another - zoom the object itself.
You see, with this kind of thinking, it doesn't matter what you present. It can be a dissection of human tissues, food chain of animal world, walking in a labyrinth, etc.
In other words, once data structure is established, putting meat on the bones is much more fathomable.
I forgot to mentions an important key benefit with the approach I described in my previous post.
When user experience is managed in parallel with data structure, you have very few, if any, conditional statements. Branching via conditionals is very cumbersome in cases with tens or hundreds variations.