Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

Collaborative interactions/asset standards

Avatar

Level 2

The concept of AFCS is now clear to me - and it’s looking good.

Are there any specific standards regarding how collaborative interactions are defined that I should be taking into consideration?

I would not want to reinvent the wheel if Adobe is planning some kind of interoperable schema. I realise 'interactions' are broad and range from describing the states of game characters to the transitions in an elearning quiz - but is there a core pattern that adobe has already identified?

Please do not misunderstand me as being 'lazy' - If a time ever came where 'we' developers shared assets across our collaborative applications then they would need to be described using a standard - I guess.

1 Accepted Solution

Avatar

Correct answer by
Former Community Member

Hi Andy,

This is a topic near and dear to me - I think the short answer is "not quite yet". AFCS, especially the client library, was born with 2 goals :

1. Make it so easy to build collaborative apps that most Flex devs can do it.

2. Lead a sea change, following from 1), which helps define what real-time collaborative workflows on the web can be.

I think it's safe to say we're still tightly focused on 1). We're moving towards commercial release, and are doing all the things it takes to get us there (most of which involves e-commerce systems). But we haven't forgotten 2). Some of the initial gestures/workflows we think are important are already included in the UI SDK, like ShareCursorPanes, WhiteBoards, and Chat. But we know there's still some distance to go. We believe the richness of the Flash Platform is a perfect vehicle to evolve multi-user UI, and devs who use our platform tend to be well-suited for this kind of thing.

So that's the long answer - we're definitely planning on diving deeper into pattern design for this sort of thing, but at the moment it's about executing the core, enabling tech.

hope that helps

nigel

View solution in original post

2 Replies

Avatar

Correct answer by
Former Community Member

Hi Andy,

This is a topic near and dear to me - I think the short answer is "not quite yet". AFCS, especially the client library, was born with 2 goals :

1. Make it so easy to build collaborative apps that most Flex devs can do it.

2. Lead a sea change, following from 1), which helps define what real-time collaborative workflows on the web can be.

I think it's safe to say we're still tightly focused on 1). We're moving towards commercial release, and are doing all the things it takes to get us there (most of which involves e-commerce systems). But we haven't forgotten 2). Some of the initial gestures/workflows we think are important are already included in the UI SDK, like ShareCursorPanes, WhiteBoards, and Chat. But we know there's still some distance to go. We believe the richness of the Flash Platform is a perfect vehicle to evolve multi-user UI, and devs who use our platform tend to be well-suited for this kind of thing.

So that's the long answer - we're definitely planning on diving deeper into pattern design for this sort of thing, but at the moment it's about executing the core, enabling tech.

hope that helps

nigel

Avatar

Level 2

Nigel,

Thankyou - I am in the picture now.

I appreciate it is difficult to conceive or conceptulise what patterns and needs might emerge at this stage. Real-time collaborative interaction is a new consideration for me and describing how an object should behave whilst being under the influence of multiple users has never been a design issue. I will no doubt discover as I get stuck in.

Thanks

Andy

The following has evaluated to null or missing: ==> liqladmin("SELECT id, value FROM metrics WHERE id = 'net_accepted_solutions' and user.id = '${acceptedAnswer.author.id}'").data.items [in template "analytics-container" at line 83, column 41] ---- Tip: It's the step after the last dot that caused this error, not those before it. ---- Tip: If the failing expression is known to be legally refer to something that's sometimes null or missing, either specify a default value like myOptionalVar!myDefault, or use <#if myOptionalVar??>when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: #assign answerAuthorNetSolutions = li... [in template "analytics-container" at line 83, column 5] ----