Plain Black, makers of WebGUI - Re: The Death of the Collaboration System

bernd

Date: 11/22/2008 2:01 pm · Subject: Re: The Death of the Collaboration System · Rating: 0

Aspects make it easier for the developers to add a more-advanced feature, instead of custom-coding a basic version by themselves.

But that is exactly what I meant! Aspects give a lot of power to developers. But what about those that are hesitant to touch the perl code? Or may not since they do not have permissions on their site? Having the choice between a fork, spoon or knife is a good thing. But what if you need the spoon and knife or even the spork? You would have to implement your own aspect in perl that mixes in all the aspects you need. Definitely not a job for designers. Therefore, a universal CS may still sometimes be useful.

--
Klettern in Magdeburg
(http://www.klettern-md.de)

Back to Top

Rate [ | ]

JT

Date: 11/22/2008 2:15 pm · Subject: Re: The Death of the Collaboration System · Rating: 0

> But that is exactly what I meant! Aspects give a lot of power to
> developers. But what about those that are hesitant to touch the perl
> code? Or may not since they do not have permissions on their site?
> Having the choice between a fork, spoon or knife is a good thing.
> But what if you need the spoon and knife or even the spork? You
> would have to implement your own aspect in perl that mixes in all
> the aspects you need. Definitely not a job for designers. Therefore,
> a universal CS may still sometimes be useful.
>

I'm not going to argue the point much further than to say this:

If you ever do actually need a spork (and who ever "needed" a spork),
then you absolutely should build it. And no it's not for a designer to
do. But it's also not something that should be in the core. I'm the
one who designed and built the collaboration system. And had I known
then what I know now, I would have never built it. It's so "powerful"
that it's the slowest asset in the system.

Back to Top

Rate [ | ]

JT

Date: 11/22/2008 2:22 pm · Subject: Re: The Death of the Collaboration System · Rating: 0

I don't want to discourage you from having a descenting opinion. It's ok that we don't agree on this.

Back to Top

Rate [ | ]

bernd

Date: 11/22/2008 2:35 pm · Subject: Re: The Death of the Collaboration System · Rating: 0

I don't want to discourage you from having a descenting opinion. It's ok that we don't agree on this.

No problem. I only made the mistake to take it personal in our first conversation. But now I got used to it.

In fact, we do not really disagree. I perfectly understand your point. All I wanted to suggest is a web front-end for plugging aspects into a "universal" (or maybe basic/simple) CS asset. The result would be the same as creating a custom CS in the perl code, except that the latter could be done by designers. There should not be any performance drawback.

--
Klettern in Magdeburg
(http://www.klettern-md.de)

Back to Top

Rate [ | ]

JT

Date: 11/22/2008 2:40 pm · Subject: Re: The Death of the Collaboration System · Rating: 0

> In fact, we do not really disagree. I perfectly understand your
> point. All I wanted to suggest is a web front-end for plugging
> aspects into a "universal" (or maybe basic/simple) CS asset. The
> result would be the same as creating a custom CS in the perl code,
> except that the latter could be done by designers. There should not
> be any performance drawback.
>

It's not actually possible. Aspects don't "magically" come together.
Each one takes some extra code to "glue" it into the other components.

Back to Top

Rate [ | ]

bernd

Date: 12/11/2008 2:30 pm · Subject: Re: The Death of the Collaboration System · Rating: 0

I just had an interesting discussion with preaction and perlDreamer on
the chat. I think it is clear to me now what you meant. Still, I think
the problem could be overcome. It would require a major API change,
however. Going to post an RFE on it.

> It's not actually possible. Aspects don't "magically" come together.
> Each one takes some extra code to "glue" it into the other components.

Back to Top

Rate [ | ]

bernd

Date: 12/11/2008 3:05 pm · Subject: Re: The Death of the Collaboration System · Rating: 0

Am Donnerstag, den 11.12.2008, 14:30 -0600 schrieb spunky@kashyyyk.de:
> bernd wrote:
>
> I just had an interesting discussion with preaction and perlDreamer on
> the chat. I think it is clear to me now what you meant. Still, I think
> the problem could be overcome. It would require a major API change,
> however. Going to post an RFE on it.

No, I changed my mind. Leave it as it is.

Back to Top

Rate [ | ]

JT

Date: 12/1/2008 11:32 am · Subject: Re: The Death of the Collaboration System · Rating: 0

It bothers me that you think you will somehow be losing something when the CS is split up into the blog, the forum, the helpdesk, and the story manager. Could you describe for me something specific you think you'll be losing, or that you won't be able to accomplish once the split is done?

Back to Top

Rate [ | ]

arjan

Date: 12/1/2008 5:36 pm · Subject: Re: The Death of the Collaboration System · Rating: 0

The idea of being able to use certain functionality with multible assets
is great. Perhaps I''m taking this to a more abstract level than is
desired, but being able to 'associate' objects more freely is something
that seems so close but still out of reach. There are a few perspectives
on this:

- reducing asset-diversity
I know the story manager is something different than the collaboration
systems and I also understand that there's overhead in making every
attachment into an asset, however ... It seems very rewarding to think
about ways to increase consistency and intuitive understanding. Wouldn't
it be great if a forum was a container of articles, if every comment was
an article and if everything that resembles an article would be an
article? Wouldn't it contribute to intuitive understanding if every
attachment was an asset. Perhaps even an asset that could be associated
with multiple other assets.

- creating (understandible) flexibility
Image functionallity like ratings that could be associated to an asset.
A rating that could take any form and could be configured by itself and
be associated to any asset. Especially the 'being a thing on itself' and
'being associated' to something is what would make it both flexible as
well as understandible to a non-programmer.

- bringing the power of creation to the designer
The last thing brings me to the designer. It's great when a listing (in
the matrix) becomes an asset, it's great that a thing in Thingy becomes
an asset. Of course it's great that aspects can be programmed in. But
it's even greater if the designer can be creative. Being able to combine
functionallity, create you own applications without programming, that
makes creative interaction. That's what makes thingy great and that's
what makes assets great now. I've attached an image where a designer
combined a poll and a collaboration system. That kind of creativity is
great I think. And it can be done by a designer because they are assets
and have an interface and there's a macro (assetProxy) to bring them
together.

I often dream - when I dream of WebGUI - of having an image-manager that
I could open from an article. It would enable me to associale an image
with the article. I could scale it, I would always keep my original (my
first revision), there would be an uniform way to use the image,
preferably in the editor. I could associate extra functionality to it,
like a rating that I configured or a poll, I could group it with other
articles and one could reply to it and those replies could be rated. For
example.

Of course - I know - this is probably a bit too much of free-thinking.
But the most essential of these goals, we often achieve with macro's
that we pass the assetId of the asset where it's in. So the
functionality can be associated to the asset. It's not ideal - nice
interface would be better - but very powerfull. And it's in the hands of
the designer. Recently I discovered how to make an assetProxy aware of
it's environment (on what page it is displayed) so we could make a very,
very general SQL rapport that displayed information based on the
metadata of the page.

In the source of Macro.pm it says that macro's should disappear. It's in
there for a long time already. When you wrote that, what ideas where
there to replace it?

*Can we image a way to give macro's (or how it will be named in another
form) an interface and a way to make it aware of the asset is displayed
in or associated to?*

Because that seems more elegant. I wonder where the idea of a light
asset which can be combined with aspects by a programmer will lead to.
In terms of asset-diversity: Won't it lead to many, many assets with
many many names? In terms of flexibility: Won't it lead to a world where
there's a programmer needed for every new combination? In terms of
bringing the power to the designer: Won't it lead to a world where at
least a sysadmin is needed to enable one of the many combinations? Or a
very large foodprint, because all combinations are enabled?

Don't get me wrong: I like and understand the idea, and the need for it:
I agree that performance is a really big issue and therefore this is
reasonable. However, I would be really interested in thinking about ways
that would make WebGUI for the designer conceptually more simple and
flexible and powerfull at the same time.

And a request about something else: if the Collaboration System dies and
- of course arises from it's ashes as a phoenix with aspects - I hope
it will be possible to create gracefully degradating templates for it.
Please contact me if about that if that's not high a enough a priority
to make it into your specs.

Kind regards,
Arjan.

jt@plainblack.com schreef:
> JT wrote:
>
> It bothers me that you think you will somehow be losing something when
> the CS is split up into the blog, the forum, the helpdesk, and the
> story manager. Could you describe for me something specific you think
> you'll be losing, or that you won't be able to accomplish once the
> split is done?
>
>
>
> http://www.plainblack.com/webgui/dev/discuss/the-death-of-the-collaboration-system/15
>
> ------------------------------------------------------------------------
>
>
>
>

Attached Files

Schermafdruk-1.png

Back to Top

Rate [ | ]

JT

Date: 12/15/2008 11:00 am · Subject: Re: The Death of the Collaboration System · Rating: 0

Wow you've written a long response here. Much appreciated. I'll do my
best to respond to each point you brought up.

> The idea of being able to use certain functionality with multible
> assets
> is great. Perhaps I''m taking this to a more abstract level than is
> desired, but being able to 'associate' objects more freely is
> something
> that seems so close but still out of reach. There are a few
> perspectives
> on this:
>
> - reducing asset-diversity
> I know the story manager is something different than the collaboration
> systems and I also understand that there's overhead in making every
> attachment into an asset, however ... It seems very rewarding to think
> about ways to increase consistency and intuitive understanding.
> Wouldn't
> it be great if a forum was a container of articles, if every comment
> was
> an article and if everything that resembles an article would be an

Whether it would or would not contribute to understanding isn't
relevant. Mainly because stories, forum posts, blog posts, and
articles all have separate sets of properties. They all have different
security needs, different demands from templating, etc. In addition,
reusing assets for things other than their intended purpose is how we
got to the point that I'm calling for the death of the Collaboration
System. When you build a sprawling behemoth such as the CS, it becomes
unruly and hard to maintain. Using articles for every different type
of post in the system, just does the same thing to the article asset.
Could these other things be subclasses of the article? Probably. But
the article is so simple that it would actually be slower to sublcass
(from an execution perspective) than to just recreate the one useful
field in the article into the individual post types.

> article? Wouldn't it contribute to intuitive understanding if every
> attachment was an asset. Perhaps even an asset that could be
> associated
> with multiple other assets.

I'm not certain if it contributes to understanding or not, but it
could certainly make the attachments more reusable.

> - creating (understandible) flexibility
> Image functionallity like ratings that could be associated to an
> asset.
> A rating that could take any form and could be configured by itself
> and
> be associated to any asset. Especially the 'being a thing on itself'
> and
> 'being associated' to something is what would make it both flexible as
> well as understandible to a non-programmer.

I'm sorry, I don't understand what you're saying here.

> - bringing the power of creation to the designer
> The last thing brings me to the designer. It's great when a listing
> (in
> the matrix) becomes an asset, it's great that a thing in Thingy
> becomes
> an asset. Of course it's great that aspects can be programmed in. But
> it's even greater if the designer can be creative. Being able to
> combine
> functionallity, create you own applications without programming, that
> makes creative interaction. That's what makes thingy great and that's
> what makes assets great now. I've attached an image where a designer
> combined a poll and a collaboration system. That kind of creativity is
> great I think. And it can be done by a designer because they are
> assets
> and have an interface and there's a macro (assetProxy) to bring them
> together.
>
> I often dream - when I dream of WebGUI - of having an image-manager
> that
> I could open from an article. It would enable me to associale an image
> with the article. I could scale it, I would always keep my original
> (my
> first revision), there would be an uniform way to use the image,
> preferably in the editor. I could associate extra functionality to it,
> like a rating that I configured or a poll, I could group it with other
> articles and one could reply to it and those replies could be rated.
> For
> example.

So why haven't you submitted each of those dreams to the RFE list?

> Of course - I know - this is probably a bit too much of free-thinking.
> But the most essential of these goals, we often achieve with macro's
> that we pass the assetId of the asset where it's in. So the
> functionality can be associated to the asset. It's not ideal - nice
> interface would be better - but very powerfull. And it's in the
> hands of
> the designer. Recently I discovered how to make an assetProxy aware of
> it's environment (on what page it is displayed) so we could make a
> very,
> very general SQL rapport that displayed information based on the
> metadata of the page.
>
> In the source of Macro.pm it says that macro's should disappear.
> It's in
> there for a long time already. When you wrote that, what ideas where
> there to replace it?

I think that macros and the templating system should eventually become
one. Macros would be functions that could be written into the
templating engine. However, we can't do that currently. In order to do
it we need to convert WebGUI to use only one template engine, Template
Toolkit. But there's lots of work to get that done. And I'm not
entirely sure that we should do it. So it's on the back burner.

> *Can we image a way to give macro's (or how it will be named in
> another
> form) an interface and a way to make it aware of the asset is
> displayed
> in or associated to?*

Well, if it's integrated into the template system then it will have
the asset id of the asset it's being rendered in. But you really
already have that with macros.

^SomeMacro();

> Because that seems more elegant. I wonder where the idea of a light
> asset which can be combined with aspects by a programmer will lead to.
> In terms of asset-diversity: Won't it lead to many, many assets with
> many many names? In terms of flexibility: Won't it lead to a world
> where
> there's a programmer needed for every new combination? In terms of
> bringing the power to the designer: Won't it lead to a world where at
> least a sysadmin is needed to enable one of the many combinations?
> Or a
> very large foodprint, because all combinations are enabled?

I can tell you where it will lead. It will lead to assets that have
fewer bugs, more consistent features, faster execution times, and
shorter RFE times.

Wouldn't you rather have a really good blog app, than a forum app that
can be sort of repurposed into a blog? Wouldn't you rather have a good
ticketing system rather than a mailing list that can sort of be used
like a ticketing system?

> Don't get me wrong: I like and understand the idea, and the need for
> it:
> I agree that performance is a really big issue and therefore this is
> reasonable. However, I would be really interested in thinking about
> ways
> that would make WebGUI for the designer conceptually more simple and
> flexible and powerfull at the same time.

These assets that I'm suggesting building to replace the CS aren't
going to be useless slouches. They'll each have huge feature sets, and
will still be able to be repurposed by designers. You'll still be able
to build amazing apps. The difference will be that they will have a
clear development path. They will be designed for one purpose and
stick to that path, so that they remain fast, robust, and
maintainable. Will there be 4 assets that replace one CS? Sure, but
they should have been that way to begin with. Will it lead to 1000 new
assets? Absolutely not. Not unless you can find 1000 truly unique uses.

> And a request about something else: if the Collaboration System dies
> and
> - of course arises from it's ashes as a phoenix with aspects - I
> hope
> it will be possible to create gracefully degradating templates for it.
> Please contact me if about that if that's not high a enough a priority
> to make it into your specs.

With the exception of the helpdesk/ticketing app, the other three
assets (story manager, forum, blog) that rise to replace the CS will
degrade gracefully. The helpdesk app we want to work like a desktop
app, not like a web page, so it falls into that "intranet" category of
apps that have no rules. The other three fall into basic and community
apps, which need to play nice with *everybody*.

JT Smith
ph: 703-286-2525 x810
fx: 312-264-5382

Create like a god. Command like a king. Work like a slave.

Back to Top

Rate [ | ]

The Death of the Collaboration System

Recent Discussions Color Key