1) I think what this idea really shows is that there are two ways of recording interaction. One as your showing, is a more abstract way less defined way (where page relationships are shown but they don't really say how one person goes from one page to another). Second, a more refined way would be to record the detailed interaction (click, hover, typing, etc) as well as giving it a specific position on a page. This idea of less defined / more defined goes 100% fully with what I've been trying to push forward with this product as part of the concept of "flexible fidelity". Namely, designers at times will sketch out work in a less or mote detailed way depending on their state of mind. One quick example of this is the text tool where you can draw a few lines of dummy text very rapidly (low fidelity) but then you can come back to it and give it more detail by typing actual words (high fidelity). So thumbs up for doing this!

2) Having said that. I say the detailed way of recording interactions (with position) as they already occur now, is priority for 0.1. I think we could do this perhaps later?

3) Perhaps you already envisioned it this way, but I think the interaction defined in the detailed way should be automatically visible in this sitemap view, in that both views are always in sync. Earlier on I've also started thinking about the concept of automatically generated site map documentation visible here:http://fluidia.org/wp/2009/03/auto-create-design-...

Having said this, I still feel we need to work more on ironing out the details of representing and recording the detailed interactions of complex interactions such as drags, movement, transitions, delays, durations and timing in the context of the existing experience thread functionality. That's probably priority for 0.1 If someone wants to take this on, that would be great. We could have a more discussion about this if required.

Sounds good?
Jakub

Nice work. Here are a few ideas or reactions from my end.

1. I really like idea of putting the project title into the browser window to conserve space. (Although the price of that is that users might notice it less).

2. Collapsible experience threads. I think we'll have to go with something like this, as at times there is no need to show them. Say when people are designing.

3. The metaphor of scenes. I noticed you used the scene / frame metaphor and I'm wondering if it might be a bit misleading. These ideas borrowed from film might suggest that there is some total unifying grand narrative (which connects scene to scene). With "threads" I was thinking to suggest that each thread is separate from one another, and more so, some threads can reference the same pages. I want to convey the notion of multiple, independent and non-linear narratives.

4. I must say I don't like the idea of vertically scrollable scenes (number 3 in your drawing.) I think there should be a way to scale and scan a larger number of scenes or threads.

5. I do believe that experience threads are a different mode of working, and so probably deserve a space of their own (on the top of the interface, separate from the current left toolbar).

As next steps, I'm thinking it might be interesting to explore such things as: recording detailed interactions (drags, clicks, movement, typing) and playing back threads.

Good work!

Jakub

On the toolkchain issue. There is _no_ problem for me to work on 'fireworks' png. I just prefer to work in a fully fledged vector environment up until the last moment (I know fireworks handles vector but it's awkward imho) so If you send me whatever styles you have in mind I'll start heading in that direction. Whatever we decide it cant hurt for me to be aware of the visual look you have in mind.

I'll also have a think about how to collaborate on visuals, interesting challenge!

1. I'd say since each object copied already contains both instance and master properties, my vote is for taking the colour out.

2. Yup. Referring to the buttons.

5. Let's try doing it. Perhaps what we need is a prototype to get a better sense of how this really feels. And of course the idea of allowing the paste selection in two ways is a good thing.

6. Agreed. Could be a label or a "fading out" cue of the whole box? Or a dotted line with a label? The idea would be to show a learnable cue as to what might eventually be removed on the next copy action (if of course the list is full).

As to the detailed visuals, as I mentioned in my previous email, I still need to figure out how to go about doing it in this public context. I do believe it might be a good idea to have the "final" file in one format (currently its a Fireworks PNG). So if you want, I could take care of it.

Cool? :)

Jakub